DEV Community: Matthias | StudioMeyer

What The Monday Report Says, And Who Wrote It

Matthias | StudioMeyer — Tue, 13 Oct 2026 21:06:19 +0000

Most websites never see anyone check them again after launch. Not out of negligence. It simply does not pay to have somebody look once a week at a site that is probably fine.

Everybody knows the result. A form has been broken for two months. A page has been loading three times slower since an update. A competitor has taken a topic you could have owned yourself. All things you would fix in five minutes on the day they happen, and that you cannot even find eight weeks later.

That is exactly what we built agents for. They now run along on most of our client sites, and the report lands in the inbox on Monday.

What An Agent Means Here

The word is currently used for everything, so briefly and concretely: an agent for us is a program with a single job that starts on a schedule, fetches its own data, evaluates it with a language model and leaves a result behind.

No chat window. Nobody types anything. They run at night, each with its own assignment, on our servers in Germany.

The specialisation matters. An agent meant to check everything checks nothing properly. One that looks exclusively at visitor numbers knows its numbers and notices when one of them steps out of line.

What The Report Says

On visitors: how many came, from where, what they clicked, where they dropped off. Not a graveyard of tables but three paragraphs with what stands out. A report nobody reads is not a service.

On competition, the question is what comparable players nearby are doing right now, which topics pull for them, where they are weak. That is where the concrete suggestions come from about what should go on the site next. It is the part that most often leads to an action.

On AI visibility, the question is whether the site is cited by language models, on which questions, and which sources stand next to it. That question did not exist two years ago. Today it matters more to some businesses than their position on Google, because a user who gets an answer in a chat never looks at a results list. Whoever does not appear there does not exist in that transaction.

On technical health it is about slow images, missing labels, broken structured data, pages that accidentally stopped being indexed. These faults never announce themselves. They cost visibility quietly, and you only find them if somebody looks regularly.

The Point Where This Differs From A Tool

There are services that will send you those numbers too. The difference comes after.

When one of our agents finds something that needs fixing, we set the fix in motion. The client does not get a list of findings plus the job of dealing with them. They get the information that it was noticed and the news that it was handled.

That is the entire difference between a monitoring tool and being looked after. A tool creates work. Being looked after takes it away. For a business with neither the time nor the interest to study charts, that is the only difference that counts.

Where The Data Comes From, And Where It Stays

The sources are the usual ones: the search engine console, the webmaster tools, the analytics tool of the site in question, and the site itself.

Consolidated, that data sits in our system with a separate data space per client. It is not passed to third parties for their own purposes. The report is written by a language model, and anyone wanting a copy of their data or the account deleted gets both.

We say deliberately that the reports are written by a model. A report pretending somebody wrote it by hand would be a small lie with the drawback of eventually being found out.

We Are Our Own Hardest Case

Everything described here runs on our own sites first. The agents check our sites, our visibility inside the models and our servers every night, and are on the table with a report in the morning.

That is not a marketing sentence, it is the reason we know the failure modes. A system you only operate at other people's places, you know from the manual. A system that catches you out early in the morning with a real problem, you actually know.

And honestly: we see the uncomfortable findings at our own place first. That is the proof that the thing works, and at the same time a good reason not to switch it off.

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

A Tool That Gets Used Outdoors

Matthias | StudioMeyer — Sun, 11 Oct 2026 23:27:05 +0000

Most software for small businesses is designed for a desk. Large screen, stable connection, quiet, time.

For a real estate office on Mallorca we built a tool for recording properties. And the place where that happens is not a desk. It is a finca in the interior, at midday, on a half-empty battery and poor reception.

That sounds like a detail. In fact nearly every decision inside the thing follows from it.

Built For The Phone, Not For The Screen

Input runs step by step rather than as one long form, and it is made for a thumb, not for a mouse.

Photos come straight from the camera. The location is taken from the device rather than typing an address that, for a plot in the interior, often does not exist. Everything saves itself continuously, and a started draft can be picked up later on the same device.

That self-saving is not a convenience but the condition for the tool being used at all. Anyone standing outside who loses half an hour of work because the connection drops does not open it a second time.

What Fits In No Field Still Needs A Place

The most important part is not a field but a note trail.

Every property carries knowledge that cannot be pressed into categories. The access road is difficult in winter. The neighbour is thinking about selling too. The permit is in progress, but not in the usual way.

A rigid form either forces that into an ill-fitting field or loses it. So a note can be added to any property at any time, without structure, without required fields. That is the catch-all for everything you cannot foresee at design time, and without it the tool would be unusable in practice.

Photos Get Resized, Not Beautified

A deliberate decision that needs explaining in the age of image generators: the tool resizes and compresses photos, and nothing else.

No brightening, no sky replacement, no removing of objects in the way. Technically that would be easy. It is still wrong, for two reasons. One is legal: showing a property differently from how it is puts you in territory where somebody eventually stands there with a lawyer. The other is practical: the prospect will stand in front of the house at some point. The gap between picture and reality is exactly the moment an appointment falls apart.

The Data Belongs To The Office

The tool can export the properties as a table and in the exchange format the large property portals read.

That sounds like a side note and is a matter of principle. Anyone maintaining their properties in a system they cannot get them out of again has made themselves dependent. The vendor can then raise the price, and you pay, because moving would cost more.

So for tools we build for clients the rule is: there has to be a way out. Not as a concession but as a design feature. A client who could leave at any time and stays anyway is the only kind of client worth having.

Roles, Because Not Everyone May Do Everything

A real estate office does not consist only of agents. There are people who find and record properties out in the field, and people who decide what goes on sale.

That separation sits inside the tool. Whoever records creates drafts and sees their own. Whoever is responsible sees everything and publishes. Between them runs a clear path from draft through review to active listing, on to reserved, sold, archived.

Without those stages you immediately get dead entries: half-finished records where nobody knows whether they are still current. With them, everybody sees at a glance where something stands.

Operable From The Chat As Well

The newer part: the tool can also be operated from an AI assistant. Instead of opening the interface, you can ask which properties are currently in review, or create a new search profile.

The benefit is not the convenience but the distance. An office tool gets opened when you have time. A question gets asked in passing. Anything that lowers the barrier between "I should" and "done" decides whether a system gets used or quietly falls idle.

What I Take From This

Before designing software for a business, you should know where it will be used. Not what it should be able to do.

A tool for the desk and a tool for outdoors look identical on a requirements list. They get built completely differently. Skip that question and you build something that convinces in the demo and sits untouched in daily work.

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

An AI Workplace That Opens In A Browser

Matthias | StudioMeyer — Sun, 11 Oct 2026 01:57:04 +0000

Most people use AI in a chat window in the browser tab next door. You type a question, copy the answer, paste it into a document. That works and is manual labour in the long run.

The next step is not a better model but a different place. The assistant should not sit next to the work, it should sit inside it.

For a copywriting studio in Germany we built exactly that: a complete workplace that opens in a browser, with the assistant right beside it.

What It Feels Like

You open an address, type a password, you are in. On the left a familiar editor window with the files, on the right a chat where the assistant thinks along. No installation, no program that has to live on one particular machine.

In practice that means the workplace is the same on the Mac at home as on the iPad on a train and on a borrowed machine in a hotel. There is no version that is newer on one device than another, and nothing you can forget to bring.

For a one-person business that is worth more than any extra feature. The alternative, a workplace that exists on exactly one laptop, is an outage waiting to happen.

The Assistant Sees The Files, Not Just The Text

The real difference to a chat window is access to documents.

A client sends a briefing as a Word file, a spreadsheet with target group data, a PDF with requirements. The assistant reads that directly, without anybody copying text out. And it writes back the same way: a Word document with headings, lists and formatting, not a block of text you tidy up by hand afterwards.

That sounds like a small thing and is the point where the time saving actually appears. Copy and paste costs only a minute in any single case. Across a month of jobs it is the difference between a tool and a toy.

The inbox is connected as well, though in one direction. The assistant can read the mail and prepare replies. It sends nothing. That is not a technical limit but a decision, and the most important one in the whole setup.

Memory Is The Part That Stays

A chat window starts from scratch with every conversation. In copywriting that is the most expensive drawback there is, because knowledge about a client is precisely what you get paid for.

So this workplace has a memory attached. It keeps clients, style rules, earlier decisions and agreements across weeks and months. On the next job the assistant knows which client needs which tone, what worked last time and what is off-limits.

That changes the nature of the collaboration. Without memory you explain the context again before every task, and eventually you stop and do it yourself. With memory, explaining pays off, because it happens once and then holds.

Two Guard Rails That Were Not Negotiable

The first concerns files. The assistant cannot delete anything unintentionally and cannot blindly overwrite a file. Anyone letting a language model work inside a directory of real client work has to build that barrier before doing anything useful with it. Otherwise the question is not whether, but when.

The second concerns style. Before every reply the assistant is handed the house style rules. Sounds trivial, but it is the difference between usable drafts and the smooth default tone everybody recognises instantly. A copywriter whose drafts sound like a text kit gets nothing out of the tool.

Where The Data Sits, And What That Actually Means

The server stands in Germany and belongs to the studio. The credentials for mailbox and documents live exclusively there and do not run through our systems.

What belongs in the same breath, honestly: whatever is sent to the language model leaves the EU, because that is where the model runs. This distinction gets blurred a lot. So on every project like this we write down what leaves the server and what does not, and the client reads it before the start, not afterwards.

Whatever access is needed for maintenance is written down in the project, traceable, and under the owner's control. That belongs settled before the start, not afterwards.

Who This Fits

Not everybody. If you use AI occasionally for a phrasing, you do not need a server of your own.

The setup pays off when three things come together: you work with it daily, you work with documents rather than only text, and it involves clients whose preferences you do not want to explain from scratch every time.

Then the maths tips over. And the difference is not that the assistant gets smarter. It is finally standing in the right place.

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

A Learning Platform Run By Agents

Matthias | StudioMeyer — Tue, 29 Sep 2026 19:06:05 +0000

The most interesting part of our learning platform is not the content. It is the question of who makes it.

The Academy is a site with lessons, recipes and guides for building your own AI systems, in six levels from the entry point to your own MCP server. It has no editorial team in the usual sense. It has a group of agents, each with a role.

The Roles

There is one that researches what is moving out there. One that turns that into topic proposals. One that writes. One that reviews what was written and is allowed to reject it. One that watches the numbers, meaning what gets read and what sits idle. And one that checks whether the site appears in AI answers at all.

That division is the actual trick. An agent reviewing its own text finds nothing. It just decided the text was good, otherwise it would have written it differently. Self-review works about as well with language models as with humans.

Separating Makes The Difference

As soon as writing and reviewing are two different agents with two different assignments, something happens.

The reviewer has no reason to defend the text. Its assignment is to find weak spots, and it finds them. Not because it is smarter, but because it is looking from somewhere else.

That same pattern now sits underneath almost everything we build with agents. One agent that builds and a second that refutes. Where the second is explicitly told to find something, not to "have a look".

What Stays With The Human Anyway

Three things.

The structure of the whole. Which six levels exist and what belongs in which is a didactic decision. An agent can propose gaps, but the build of a course is an opinion about how people learn.

The release. No text goes live without a human. That is not a question of quality but of liability: what stands on a page is the operator's responsibility, not the model's.

And the tone. A model writes correctly and interchangeably. The difference between an explanation that lands and one that is accurate is still handmade.

Why The Topic Agent Is Tied To The Structure

An agent proposing topics while only looking at what is currently in season produces pieces about whatever is currently in season. That is not a course, that is a news ticker.

So it hangs off the course structure rather than the news cycle. It proposes what is missing at a given level, not what is being searched for a lot. Fewer proposals, and usable ones.

What It Is Good For

The Academy sells nothing. It is free and needs no account.

The reason we run it anyway is twofold. First, it is the best rehearsal we have: whatever we claim about memory-first working and agent patterns has to stand there in a form somebody without our backstory understands. Anyone who cannot explain something has not understood it.

Second, it is the evidence. A learning platform run by exactly the kind of system it explains is a different kind of proof than a reference list.

When the operation slips, you see it there first. That is uncomfortable and precisely the point.

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

An Agent Fleet, Sorted By Job

Matthias | StudioMeyer — Tue, 29 Sep 2026 17:26:56 +0000

"We have agents" is about as informative as "we have software". The question is what they do, when they run and who notices when one stalls.

Ours grew into a fleet step by step. Not planned but grown: every single one came into being because a job was too regular to do by hand and too ambiguous to pour into a script.

This piece describes the groups, not each individual. A list of all the names would be an enumeration without insight.

The Rule Behind The Split

An agent has one job. Not two.

That sounds like bureaucracy and is the reason the fleet works. An agent meant to check analytics and also watch competitors does both mediocrely, and when the result is poor you do not know which half caused it.

Two agents with one assignment each are sharper and, more importantly, judgeable separately. You can improve one without touching the other.

The Groups

Leadership are agents that summarise rather than work themselves. They read what the others produced overnight and turn it into a report of what needs attention. Without that layer you would get a pile of separate notifications in the morning and read none of them.

Engineering looks at the code and the systems. What has grown, where warnings pile up, which dependency has a known hole, where the architecture has drifted from what is documented.

Content covers research, topic proposals, drafts, review. Always with separate roles for writing and reviewing, because an agent reviewing its own text finds nothing.

Visibility covers search engine standings, mentions in AI answers, visitor numbers, what competitors are doing. This group runs for our own sites and for client sites.

Operations handles servers, backups, certificates, containers, cost. The most thankless group, because its best day is the one where it reports nothing.

Review consists of agents whose only purpose is to attack the others' work. They write nothing and build nothing. They look for faults in whatever just got finished.

The last group is the one that delivers most.

Why The Reviewer Needs A Role Of Its Own

A model that built something and is then asked whether it is good says yes. Not out of malice, but because it just built the thing the way it thought was right.

A reviewer with its own assignment behaves differently, especially when the assignment is not "review" but "refute". The hardest findings come from that group, including on things that had already passed other checks.

It gets better still when the reviewer comes from a different model family than the builder. Two models from the same house make similar mistakes and overlook each other.

What Happens At Night

Most of it runs when nobody is around. That has a practical reason: an agent that takes a long time for a pass is in the way during the day, and nobody likes waiting for a report.

In the morning the result is there. Not as raw data but as text with what stands out. A report consisting of numbers without interpretation stops being read after two weeks.

What They Are Not Allowed To Do

None of these agents sends a mail to a client. None changes anything on a client site without a human in between. None deletes anything.

That is the hardest boundary in the whole setup, and it is deliberately enforced technically rather than merely stated as an instruction. An instruction is a request. A tool an agent does not have in the first place is a boundary.

The Number, And Why It Is Not Here

It would be easy to name a figure. It sounds good and is almost always misleading.

Count files and you get a large number that includes helper parts and sub-agents which never run alone. Count only what starts on a schedule and it is fewer. Count what produces something daily that a person reads and it is fewer still.

All three numbers are correct and mean different things. So we would rather name the groups and what they do. Anyone who needs a figure should always ask what was counted.

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

EU-Sovereign AI: Why We Don't Put Inference in the US Cloud

Matthias | StudioMeyer — Sun, 27 Sep 2026 21:03:01 +0000

When we build a chatbot for a client project, generate a product image or clone a voice, something happens in the background that almost nobody talks about: the actual compute work runs on servers in the United States, nearly every time. Replicate, fal.ai, OpenAI, Together, half the industry sits there. For a German tax firm or a hotelier on Mallorca, that means their prompts, images and sometimes customer data travel across the Atlantic and back. This is the blind spot of the current AI wave, and we deliberately handle it differently.

What AI inference actually is

Short and without jargon: an AI model has two phases of life. Training is the expensive, one-time part where the model learns. Inference is what happens millions of times afterwards, every time someone asks a question, generates an image or turns a voice message into text. Every chatbot sentence, every generated photo, every text-to-speech readout runs an inference.

That compute work needs specialized graphics cards that very few companies run themselves. So you rent them as an API from a provider. You send the prompt, get the result back, pay per use. Convenient, cheap, scalable. And in the vast majority of cases, that provider's server sits in Northern Virginia, not in Frankfurt.

Why the US cloud is a real GDPR problem

This isn't a gut feeling, it's the legal reality. Two things interlock here.

First, the US CLOUD Act of 2018. It obliges US companies to give US authorities access to data on request, no matter where in the world that data physically sits. A US provider with a data center in Ireland is just as affected as one in Texas. The server location alone does not solve the problem.

Second, the shaky legal basis for the data transfer itself. In 2020, the European Court of Justice struck down the then-current Privacy Shield in its Schrems II ruling. Its successor, the EU-US Data Privacy Framework of July 2023, is already under fire again, with a member of the European Parliament having filed a challenge before the EU's General Court. Anyone basing their data processing today on this single adequacy decision is building on a foundation that has already wobbled twice in recent years.

For most small businesses this stayed abstract for a long time. With AI it becomes concrete, because suddenly real content flows through these pipelines: a patient's email to the practice chatbot, a property photo sent off for editing, a guest's recorded voice message. These are exactly the kind of data the GDPR is meant to protect.

What EU-sovereign inference means

The countermovement is called sovereign AI. The core idea is simple: the compute, the models and the contracting party all sit in Europe, are subject to European law and to no CLOUD Act. Your data does not leave the European legal space.

To be honest, sovereignty here is a spectrum, not a switch. Some providers run their own hardware in European data centers, others route through European regions of larger cloud providers, and still others aggregate third-party models and put a European contract and billing layer on top. The practical gain is the same in all cases: a European point of contact, GDPR-native contracts, data residency in the EU, and a provider who understands why that is not a mere formality.

An example right on our doorstep: Socaity

When a project needs image, voice or video generation, we look for the compute in Europe first. One of the providers we work with for this happens to sit five minutes from our office, in Palma de Mallorca: Socaity.

Socaity bundles AI models for image, video, voice, 3D and text recognition behind a single API, with European routing, one contracting party and one invoice. The approach is deliberately built to be EU-sovereign, the company is based in Palma, the data processing is GDPR-native. Instead of signing up with five different US services and clarifying data processing with each one separately, you get one European gateway to many models.

For us this is more than a technical footnote. It is a concrete piece of infrastructure from our own ecosystem, built by a founder who comes from twenty years of hand-written code and treats sovereignty not as a marketing label but as an architectural decision. Exactly the kind of partner we want to work with.

What this means for your project

Concretely, it means the question of where the servers sit belongs in the planning phase, not in the privacy policy at the end. Before a chatbot or an image pipeline enters a project, we clarify where the content gets processed. For anything involving personal or sensitive data, the European option is the default, not the exception.

That rarely costs more and delivers two things at once: legal calm and an honest selling point. A hotelier who can tell guests that their requests never leave the EU has a trust argument a US pipeline will never provide. It fits the way we build anyway: the websites we ship are hosted on European servers, GDPR-compliant and without tracking cookies. The inference layer is the logical continuation of the same stance.

Honestly: the limits

To keep it fair. Europe's providers are smaller today than the US giants. The model selection is sometimes narrower, some new models appear on US platforms first, and part of the EU providers themselves pass larger catalogs through in the background. Anyone looking for the absolute biggest model buffet at the lowest price per call still often lands at a US service for now.

So the honest trade-off isn't "EU always and everywhere," but: where personal data flows, legal certainty outweighs the last cent of price difference. Where it's about purely internal, anonymous experiments, a US service can be perfectly fine. We make that distinction per project, not by dogma.

The takeaway

The AI wave has a quiet side effect: it is currently sending a great deal of real customer data from a great many small companies through American data centers, usually without anyone having asked the question. For us, that question belongs in the first planning round, not in a footnote. European inference is mature enough today to be taken as the default without giving up quality. And the fact that one of the providers for it sits a few streets away in Palma only makes the decision easier. If you want to know how we implement this in a concrete project, get in touch or take a look at how we work.

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

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.