DEV Community: Matthias | StudioMeyer

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.

MCP Transports: stdio vs HTTP, and What Just Changed

Matthias | StudioMeyer — Sun, 16 Aug 2026 05:33:47 +0000

Our own search data has been telling me to write this for months and I ignored it. Thirty-one different spellings of the same question, things like "stdio vs http mcp" and "mcp server stdio vs http", nearly three hundred impressions, several of them sitting on page one. Zero clicks, because we rank for it by accident out of other articles and have never had a page that actually answers it.

So here is the page. And writing it turned up something I did not expect: most of what you will find on this question, including the top results, describes a version of the protocol that has been replaced.

The Short Answer

If a single client launches the server on the same machine and it touches local files, local databases or local tools, use stdio. If the server has to be reachable over a network, serve more than one client, or run somewhere you deploy rather than somewhere you sit, use Streamable HTTP.

If you are about to build on HTTP+SSE, the two-endpoint transport from the 2024-11-05 revision, do not. It has been deprecated since 2025-03-26, new implementations should not adopt it, and it is eligible for removal in a future revision.

That covers most decisions. The rest of this article is about the parts that bite after you have chosen.

stdio: One Pipe, and One Bug Everybody Writes

The client launches your server as a subprocess and talks to it over standard streams. The server reads JSON-RPC from stdin and writes JSON-RPC to stdout, one message per line, newline-delimited, and messages must not contain embedded newlines.

Now the rule that breaks more stdio servers than anything else, and it is worth quoting because people skim past it: the server MUST NOT write anything to its stdout that is not a valid MCP message.

That means every print(), every console.log(), every stray debug line from a library you imported goes straight into the message channel and corrupts the protocol. The client sees malformed JSON where it expected a response. Symptoms range from a tool that never returns to a server that appears to connect and then dies on the first call.

The fix is in the same paragraph of the spec: stderr is yours. The server may write UTF-8 to stderr for any logging purpose, and the client may capture, forward, or ignore it. The spec is explicit that the client should not treat output on stderr as an error condition. So route your logging there and leave stdout alone.

Two more things worth knowing. Shutdown is initiated by the client closing your input stream, so a server should exit promptly when stdin reaches end of file. That is the primary graceful shutdown signal and, per the spec, the only portable one. And if your process dies unexpectedly, the client should restart it. Because the protocol is stateless, in-flight requests are simply lost, and the client can retry them against the fresh process. Note the wording: they are lost, not automatically replayed. Whether a retry happens is your caller's decision, not something the transport does for you.

Streamable HTTP: One Endpoint, One POST per Message

The server exposes a single HTTP endpoint that accepts POST. Every JSON-RPC request or notification is its own POST. For a request, the server answers with either a single JSON object or an SSE stream scoped to that request, carrying progress notifications and then the final response. For a notification there is no JSON-RPC answer at all: an accepted notification gets HTTP 202 Accepted with no body.

Three requirements on the client side are easy to miss. The Accept header must list both application/json and text/event-stream, because the server chooses per request which one it sends and the client must handle both. The body must be a single JSON-RPC request or notification, never a response. And the request metadata headers, which I come to next, are mandatory.

For long-lived server-to-client notifications there is now a dedicated mechanism: you send a subscriptions/listen request, and its response stream stays open carrying only the notification types you opted into. Request-scoped notifications like progress do not travel on that stream; they flow on the response stream of the request they belong to.

What Changed in the 2026-07-28 Revision

This is the part that makes most existing write-ups wrong, including a fair number of tutorials published this year.

Protocol-level sessions are gone. Earlier revisions let the server assign a session through an Mcp-Session-Id header, terminated with an HTTP DELETE. That mechanism is not part of the current revision. A server implementing only the new revision should ignore an incoming Mcp-Session-Id header entirely and must not mint or echo session ids.

The standalone GET stream is gone. Clients used to open a separate SSE stream with a GET request to receive server-initiated messages. Removed. A server that supports only this revision should answer GET or DELETE on the MCP endpoint with 405 Method Not Allowed; servers that still speak the older revisions alongside it obviously keep handling them.

Resumable streams are gone. Last-Event-ID is not supported. A server built only for this revision should ignore that header, along with any incoming Mcp-Session-Id.

Servers no longer send their own requests. When a server needs something from the client, sampling, elicitation, or roots, it used to send a JSON-RPC request down an SSE stream. Now it returns an InputRequiredResult and the client retries the original call with the answers attached. This is called Multi Round-Trip Requests, and it is a real change in control flow, not a rename.

And the initialize handshake itself is now the legacy path. Modern revisions carry the protocol version, client capabilities and client identity per request, in _meta.io.modelcontextprotocol/* fields, rather than establishing them once in a connection-scoped handshake.

If you have read any of this in a guide that still shows Mcp-Session-Id bookkeeping and a GET stream, that guide is describing the 2025-03-26 through 2025-11-25 shape. That shape is not wrong history, and plenty of deployed servers still speak it, but it is not what you should be building against now.

Three Headers That Are Now Mandatory

Streamable HTTP mirrors selected body fields into HTTP headers so that load balancers, gateways and observability tooling can route and inspect requests without parsing the body.

Every POST to the MCP endpoint must carry MCP-Protocol-Version, for example MCP-Protocol-Version: 2026-07-28. Mcp-Method is required on all requests, and Mcp-Name on tools/call, resources/read and prompts/get, carrying the tool name, the resource URI or the prompt name respectively.

Here is the trap: the header value must match the corresponding value in the body. If it does not, the server must reject the request with 400 Bad Request and JSON-RPC error -32020, named HeaderMismatch. The reasoning is a genuine security concern rather than pedantry. If a load balancer routes on the header while the server executes on the body, and the two disagree, you have a request that goes to one tenant's infrastructure and runs another tenant's call.

Values that cannot be safely written as plain ASCII, anything non-ASCII, control characters, or leading and trailing whitespace, must be Base64-encoded with the sentinel format =?base64?VALUE?=. Servers decode that before comparing to the body.

The Security Rules for HTTP, Which Are Not Optional

Three requirements, and the first one is the one people skip.

Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks, and must answer an invalid Origin with 403 Forbidden. Without it, a website your user visits in a browser can reach a local MCP server on their machine and drive it. That attack works precisely because the server is local and trusted.

When running locally, servers SHOULD bind only to 127.0.0.1 rather than 0.0.0.0. Binding to all interfaces on a laptop puts your tool server on every network that laptop joins, including hotel wifi.

And servers SHOULD implement proper authentication on all connections. The transport binding itself does not prescribe a mechanism, so which one you use is a decision you make deliberately rather than one the transport makes for you. In practice that means the authorization the MCP spec defines separately, or a bearer credential you control.

None of these apply to stdio, which is a large part of why stdio remains the right choice for local work. There is no port, no origin, and no listening network surface, so the process boundary is the transport's security boundary.

One thing stdio does not give you, and this is worth saying because it is widely assumed: it is not a guarantee that your data stays on the machine. The transport is local, the server's behaviour is not. A stdio server is an ordinary process that can open any outbound connection it likes, and plenty of them exist precisely to call a remote API on your behalf. stdio tells you how the client talks to the server. It tells you nothing about where the server sends things afterwards.

Choosing, in Table Form

	stdio	Streamable HTTP
Who starts the server	the client, as a subprocess	you, independently
Reachable by	that one client	anything that can reach the URL
Network surface	none	a port, with all that follows
Cancellation	`notifications/cancelled`	close the request's stream
Auth	process boundary	OAuth 2.1 or bearer, plus Origin checks
Scheduled and headless use	needs a process to launch it	natural fit
Typical case	local files, local database, IDE tooling	hosted API, team server, SaaS

The decision is rarely close in practice. What is genuinely worth thinking about is the case where a vendor offers both, which is increasingly common: a local package you install and a hosted endpoint you point at. There the deciding question is not technical elegance but who holds the credential and what the server does with it. A local package keeps the credential on your machine, which is a real difference. It does not, as the previous section says, keep your data there. If that distinction matters for your use case, the answer is in the server's behaviour and its privacy terms, not in its transport.

Two Things I Would Check Before Building

Check which revision your client actually speaks, not which one the docs describe. The spec carries an explicit version-negotiation and fallback procedure precisely because the field is split across revisions right now, and it recommends probing before the first real request even for clients that only support modern versions. The payoff is that a mismatch fails predictably instead of a legacy server quietly processing your call under different semantics.

And if you are writing a stdio server, put a lint rule or a test on it that fails when anything reaches stdout outside the message writer. It is the single cheapest guard against the one bug that costs everyone an afternoon, and it takes less time to add than the first debugging session it prevents.

The transports themselves are not complicated. What makes this topic confusing is that the ground moved recently, and most of the writing about it has not caught up. If you take one thing from this article, take the habit of checking the revision date on whatever you are reading.

This article was originally published on studiomeyer.io.

Codex Now on Your Phone: Mobile Plus Goal Mode Explained

Matthias | StudioMeyer — Thu, 13 Aug 2026 13:32:32 +0000

In mid-April, OpenAI Codex had two million weekly users. Six weeks later it has four million. The growth was not the news. The news was what shipped in between to make the next two million possible.

Two updates in particular matter for people who already use ChatGPT and read our April Codex guide. The first is Codex Mobile, which left the Plus-only bucket on May 14 and is now part of every ChatGPT plan including Free and Go. The second is Goal Mode, which exited the experimental flag on May 21 and is now generally available across the web app, the desktop app, the IDE extension and the CLI.

Neither of these is a new tool. Both are upgrades that change how Codex fits into a real workday. This article is for readers who liked the April beginner's guide and want to know what the May updates actually do, without the OpenAI marketing copy and without code.

What changed in six weeks

Six features shipped between April 16 and May 22. The user count doubled. GPT-5.5 became the default model behind Codex. Codex Mobile got freed up to every plan. Goal Mode reached general availability. Appshots, which let you attach any macOS window to a Codex thread by hotkey, also went general. A Chrome extension launched that lets Codex work inside live browser sessions instead of in a sandbox.

That is a lot for six weeks. The April guide covered five surfaces. The list has not grown, it has deepened. The same five Codex environments (Web, iOS, Desktop, VS Code, CLI) now do more with less setup. Two of those changes are big enough to be worth their own walkthrough.

Goal Mode in one sentence

Goal Mode is the difference between asking Codex to do a task and asking Codex to reach an outcome.

In normal Codex use, you give it an instruction like "draft this email" or "summarize this PDF." Codex returns a result and waits. If the result is not quite right, you give it follow-up instructions. The interaction is turn by turn.

In Goal Mode, you describe the end state and the success criteria. Something like "prepare a clean handoff document for the new freelancer covering everything she needs for the next two weeks. It should be self-contained, written in plain English, and include links to the three relevant Notion pages." Codex breaks that into steps on its own, executes them in sequence, checks its own work against your criteria, and only comes back when it thinks it is done or when it needs your decision on something it cannot resolve.

This is what the April post promised in one line that turned out to be the most quoted line of the whole article. "Codex executes, ChatGPT replies." Goal Mode is the version of that promise that is actually delegation rather than execution. The previous Codex felt like an assistant who needed instructions for every step. Goal Mode feels like an assistant who reads the brief and gets back to you when there is a question.

What Codex Mobile actually is in May 2026

Mobile is the part most people get wrong. Codex Mobile is not a smaller Codex that runs on your phone. It is a remote control for the Codex that already runs on your Mac.

You start a task on the desktop. You walk to a meeting. The phone shows you the live progress, lets you read intermediate outputs, approve actions Codex wants to take, switch models if the task is heavier than expected, or start a new task that runs in parallel. When you come back to the desk, everything is in the same state. The model did not pause when you closed the laptop. It kept working because the work was never on your laptop in the first place.

Two practical consequences come from this. First, you can decide that the Mac stays plugged in and unlocked at the office or at home, and the phone is your travel device. The Mac is the workshop, the phone is the dashboard. Second, you stop thinking of mobile as a downgraded version of the real tool. Mobile is the part that goes with you, not the lesser version of what stays at the desk.

The May 14 launch removed the Plus-paywall on this. Everyone with a ChatGPT account, including Free users and ChatGPT Go subscribers, can install the latest ChatGPT app on iOS or Android and find Codex inside it. The Mac host requirement still applies for the full feature set, but the basic monitoring and task-handoff functions work on phone alone.

Your first Goal Mode moment in five minutes

Open Codex on the web at chatgpt.com/codex. Look for the toggle labeled Goal Mode in the input area, or use the slash command /goal. Both routes work.

For the first try, do not pick a coding task. Try something like this. "Goal: I have an unread inbox with twelve emails from clients. Read all of them and prepare a triage list. Group them into reply now, reply this week, do not need a reply, and unclear. For each one in the reply now group, draft a short response based on what I usually write. Success criterion: I can act on the triage list in under ten minutes."

Hit run. Codex will work for several minutes, sometimes longer than expected. You can close the browser. When it is done, you have a structured triage list and three or four draft replies that match your own tone if you have been using ChatGPT consistently long enough that the model knows how you write.

The first time this happens, the difference from regular ChatGPT is obvious. ChatGPT would have replied to one email at a time. Codex in Goal Mode worked through all twelve, made its own classification, drafted responses, and packaged everything into a single deliverable. That is the move you do not get from a chat interface.

Ten Goal Mode tasks that have nothing to do with code

These are the tasks where I have seen Goal Mode deliver consistent results for solo operators and small teams in the last two weeks.

Triage a client inbox at the start of the day and produce a sorted action list. Take a meeting recording transcript and produce both meeting notes and a to-do list for each participant. Read a long PDF contract and produce a list of every change since the previous version. Translate a multi-page document and run a glossary consistency check so the same term is rendered the same way every time. Take a folder of receipts as images and produce an Excel-ready table with date, vendor, amount and category. Compare two Notion pages and produce a third page that merges them without duplicates. Take an outline and turn it into a slide deck with speaker notes. Prepare a freelancer handoff covering background, current state, deadlines and contact list. Read fifty job applications against a job description and produce a ranked shortlist with one-line reasoning per candidate. Run a competitive scan across five named competitor sites and produce a one-page summary of what is new.

None of these require GitHub, code, or technical setup. All of them benefit from Goal Mode because the work is not one prompt and one reply. The work is a sequence of small judgments that adds up to an outcome.

What Codex Mobile is for in the workday

The mistake I see in early Codex Mobile use is starting big tasks from the phone. That works, but it is not the strength. The strength is monitoring and handoff.

In practice, the pattern that works looks like this. At the start of the workday, on the desktop, you set up two or three Goal Mode tasks that will take twenty to forty minutes each. You go to a meeting, a workout or a coffee. The phone shows you live updates. When a task asks for a decision, you tap to approve or redirect. When a task finishes, you see the result and either accept it or ask for changes. By the time you are back at the desk, two of three tasks are complete and one is waiting for your input.

The other Mobile pattern is starting small tasks while you are out. Something you would have written down in Notes to do later becomes a Codex task started immediately from the phone. By the time you get to the desk, the first draft is already there.

The honest limit is that Mobile is dependent on the Mac being awake and online. If your laptop is closed in your bag, the cloud version of Codex still runs but the Mac-host features pause. For pure cloud tasks, Mobile works the same as Web. For tasks that need your local environment, the Mac has to be available.

Goal Mode versus normal Codex tasks

Goal Mode is not always the right choice. Normal Codex tasks still make sense for fast one-shots where you know exactly what you want and the work is a single transformation.

Use a normal task when you want a single output and you can describe it precisely in one sentence. "Rewrite this paragraph to sound less formal." "Translate these three sentences to Spanish." "Format this list as a Markdown table." These are not goal-oriented. They are transformations. Codex handles them faster without Goal Mode.

Use Goal Mode when the work is multi-step, when success depends on a sequence of decisions, when you want to specify outcomes rather than steps. The triage, the handoff document, the contract diff, the competitive scan. These benefit from the model planning its own approach instead of executing your micro-instructions.

A useful heuristic. If you would explain the task to a junior assistant in one breath, use normal Codex. If you would brief a freelancer for a half-day project, use Goal Mode.

The stumbling blocks I have seen

Three patterns trip people up in the first two weeks of using Goal Mode.

The first is over-defining the success criteria. "Success: the document is clear, complete, accurate, well-formatted, free of errors, and matches my style" reads like a thorough brief but tells Codex nothing it can check against. Codex evaluates its own work against criteria it can measure. "Success: every email has a draft reply under 80 words" is checkable. "Success: the document is good" is not.

The second is treating Goal Mode like a fire-and-forget machine for sensitive work. Goal Mode is autonomous in its planning, not in its judgment. A finished output still needs your read. The point of Goal Mode is that you read once at the end instead of reviewing every step, not that you never read.

The third is forgetting that Codex still has limits on long-running tasks per plan. Plus users will hit the wall on three or four long Goal Mode sessions per week. Pro users have ten times that. The cost calculation for which plan to pick changes the moment you start doing real work in Goal Mode, because each session uses more compute than a regular task.

If you bumped from Plus to Pro after the April guide, you are in the right plan. If you stayed on Plus and Goal Mode now fits your workflow, the math has shifted.

What is still coming this year

The same product strategy that surfaced in March is still on the rails. OpenAI is collapsing ChatGPT, Codex and the Atlas browser into a single desktop super-app over the rest of 2026. The April update was one step. May was another. The next steps that have been hinted at publicly include persistent cross-app memory, deeper Goal Mode integration with the Atlas browser, and a unified billing model that stops separating the chat side from the agent side.

If you spent six weeks learning Codex, none of that is wasted. The concepts are the same. The packaging gets simpler.

When Goal Mode is not for you

If you mostly use ChatGPT to look up facts, draft single short messages, or have conversations to think out loud, Goal Mode is overkill. The chat surface does that work better and faster.

If you do not have at least one recurring task per week that takes longer than fifteen minutes to do yourself, Goal Mode will not give you back enough time to justify the learning curve.

If your work is highly sensitive and you cannot have any task run autonomously without a human in the loop on each step, normal Codex with manual approvals is closer to the right tool.

For everyone else, the math is straightforward. Pick two recurring tasks. Convert them to Goal Mode briefs once. Reuse those briefs every week. The time saving compounds because you stop writing the same instructions over and over.

What to do next

If you read the April guide and never went past Codex Web, go back to chatgpt.com/codex and switch on Goal Mode for the next task you would normally type as a chat. Watch what changes.

If you read the April guide and have been using Codex Web regularly, install the ChatGPT app on your phone if it is not there already, and let Mobile run as a dashboard while you set up a Goal Mode task at the desk. The first time the phone tells you the task is done while you are in a meeting, the pattern clicks.

If you read our follow-up on Codex memory and connected an MCP memory layer, Goal Mode reads from the same memory. A Goal Mode brief can reference past decisions, client profiles and project notes without you pasting them in each time. That is when the workflow stops feeling like AI and starts feeling like a team.

And if you want help wiring Codex, Goal Mode, mobile and a memory layer into the actual workday for a small team, that is what we do at StudioMeyer. The Setting up an AI system is a six-week build that does exactly this for SMEs who have been paying for ChatGPT Plus for months and never quite turned it into a working tool.

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

Your Top 10 Ranking Stopped Delivering Clicks

Matthias | StudioMeyer — Thu, 13 Aug 2026 12:35:41 +0000

A page that holds a top ten spot and gets almost no clicks used to mean something was wrong with it. Bad title, weak description, mismatched intent. You rewrote the snippet, waited a few weeks, and the clicks came.

I ran exactly that repair on one of our own pages in May. New title, sharper and more specific, written against the search intent rather than the topic. Then I left it alone for two months and measured. The click-through rate stayed where it was, around a tenth of a percent, while the page held its position and kept collecting impressions.

That result was more useful than a success would have been. It ruled out the explanation everyone reaches for first, and it forced me to look at what had actually changed.

The Position Is Fine. The Result Page Is Not.

For a growing share of informational searches, Google answers the question above the results. The user reads the summary and never scrolls. Your listing is still there, still ranked, still counted as an impression. It simply sits below the point where the search ends.

I should be precise about what I can and cannot prove here. Search Console gives you position and clicks; it does not tell you which result page carried an answer box. What I have is a strong correlation on our own data plus the failed title test, and the explanation that fits both. If you want certainty for your own pages, search the affected queries yourself and look at what sits above the first organic result. That takes ten minutes and beats any inference.

For the page I tested I did run that check, and what sits above the organic results explains the flat click line better than anything on the page does. So for this one case I am comfortable saying it was neither a penalty nor a content problem. For your pages that remains a hypothesis until you look.

What makes it hard to see is that every dashboard still reports the old metrics as if they meant the old things. Position two looks like a win. Impressions climbing month over month looks like growth. Only the click column tells you the truth, and it is the one column people explain away.

How to Recognise It in Your Own Data

There is a signature, and you can check it in Search Console in about ten minutes without any tools.

Look for pages with a high impression count, a stable position in the top ten, and a click-through rate near zero. Not low, near zero. A weak title still produces a real rate, just a disappointing one. What I am describing produces something closer to nothing at all, across hundreds of impressions, month after month, without moving.

Then look at what those queries actually are. On our own pages the affected ones were questions. Definitional searches, "what is" and "how does", the exact shape of query that an answer box handles completely. The commercial queries on the same domain still converted impressions into clicks at an ordinary rate, because a summary does not finish that job.

That split is the useful part. It tells you which of your pages are affected and which are not, and it stops you from applying the wrong fix to the whole site. I would not assume our split generalises to your site, but the check takes ten minutes and tells you your own.

Why the Failed Repair Was Worth More Than a Fix

I want to stay on the title rewrite for a moment, because the way it failed is the most useful thing in this article.

The standard advice would have had me rewrite, see no improvement, and conclude the new title was not good enough either. Then rewrite again. That loop can absorb months, and it never terminates, because you can always imagine a better headline.

What stopped it was writing down beforehand what a success would look like. A meaningful lift within eight weeks on a page whose position was already stable. When the eight weeks produced nothing, the hypothesis was dead and I had to look elsewhere. Without that number written down in advance, I would have squinted at a flat line and found something encouraging in it.

This applies well beyond titles. Most SEO work is untestable in practice because nobody says in advance what would count as the measure failing. If your agency proposes a change, ask what result would prove the change did not work, and by when. A proposal that cannot fail cannot be evaluated, and you will pay for it either way.

Three Things That Actually Move

Look at other search engines, because they did not all change at once. This was the finding that surprised me most. I took a page whose Google click-through rate had collapsed and pulled the same query set from Bing Webmaster Tools. Same page, same search terms, roughly four percent click-through rate against a Google figure that rounds to zero.

Bing is smaller, and for most businesses it will not replace Google traffic. But it is not nothing, and the effort required is close to zero because your pages already rank there. In the client accounts I have looked at, a claimed Bing Webmaster property is the exception rather than the rule, which means the channel is usually not even being measured. Whether that traffic converts as well as Google's is something I have not measured and would not claim.

Push the position instead of polishing the snippet. If the answer box is taking the click, cosmetic changes below it are wasted. The lever that remains is moving genuinely higher, and the cheapest candidate is internal linking, because most sites have valuable pages carrying a single incoming link from their own navigation and nothing else. I would call this the best available bet rather than a proven fix: it is cheap, it is under your control, and unlike a title rewrite it addresses the thing that actually changed.

Write to be the source, not to win the click. If the summary is going to be read either way, the question becomes whether it is built from your material. That means content an answer engine can lift cleanly: a direct answer near the top, specific numbers, clear structure, and something genuinely yours in it, a measurement or a case that exists nowhere else. The reasoning is simple enough that it does not need a study behind it. A summariser has to choose what to quote, and material that exists in fifty other places gives it no reason to name you.

What to Stop Measuring the Old Way

Rankings as a standalone success metric no longer survive contact with reality. A report showing a climb from position eight to position three is not a result if the click column did not move, and any agency handing you that report without the click column next to it is showing you the wrong number.

The same applies to impressions. Impressions rise when Google shows you more often, including on queries that get answered above you. Rising impressions with flat clicks is not momentum, it is the pattern described in this article.

What I would put in a report instead: clicks by intent category, so commercial and informational pages are never averaged together. Click-through rate compared against your own history rather than an industry benchmark. And traffic from every search source you have, not just the biggest one.

Answer Searches and Buying Searches Need Different Pages

The practical consequence of all this is that one content strategy no longer covers both halves of your site.

Answer searches, the "what is" and "how does" queries, are the ones being absorbed. Pages built for them still have a job, but the job changed. They are now there to establish that you know the subject, to be quoted, and to catch the small share of readers who want more than a summary. Measuring them by sessions will make them look like failures even when they are working.

Buying searches held up in our data and I expect them to hold up longer, for a structural reason rather than a measured one. Somebody looking for a supplier in their region, comparing options, or ready to make contact still needs to arrive somewhere and speak to someone, and a summary cannot complete that. These pages deserve the disproportionate share of your effort now, and for most small companies they are the underbuilt half, because informational content is easier to produce and feels more productive.

If you only change one thing after reading this, separate those two page types in whatever report you look at. The moment they stop being averaged together, most of the confusion about whether SEO still works resolves itself.

The Uncomfortable Part

If most of your traffic came from informational content, you should plan on the assumption that a part of it is not coming back. I cannot prove that as a permanent state, and anyone who tells you they can is guessing with more confidence than I have. But planning around it costs you nothing if you are wrong, and the alternative is spending another year improving titles on pages whose problem sits above them on the result page.

The useful response is to move the effort to where clicks still exist. Commercial and local searches, where a summary cannot finish the transaction. Channels you already rank in but never measured. And content strong enough to be quoted, which builds recognition even when it does not build sessions.

None of that is as satisfying as a ranking chart pointing up. It has the advantage of being true.

One Test You Can Run This Week

Open Search Console, filter to the last three months, and sort your pages by impressions. Take the ten with the most impressions and look only at the click column. Several near zero while holding a top-ten position gives you your candidate list, not your diagnosis. Take three of those queries, search them, and look at what occupies the space above the first organic result. That is the step that turns a suspicion into an answer, and it is the one everybody skips.

Then open Bing Webmaster Tools, add the same site, and give it long enough to collect a meaningful sample. Compare the click-through rate on the same queries. If the gap looks anything like the one I measured, you have a channel that is already sending you traffic and that nobody on your side is measuring or working on. Claiming it costs you an afternoon.

This article was originally published on studiomeyer.io.

Agentic AI in German: The Words, the Law, the Numbers

Matthias | StudioMeyer — Mon, 10 Aug 2026 22:32:52 +0000

German does not have a word for agentic, and the workaround the industry settled on is a bad one.

"Agentisch" exists as a loan translation and appears in analyst reports, but nobody says it out loud in a meeting. What people actually say is KI-Agent, which means AI agent, the noun. So the German conversation collapses the adjective into the object, and a distinction that is load-bearing in English quietly disappears. In English you can say a system is somewhat agentic. In German you either have a KI-Agent or you do not, and that binary is a genuinely bad fit for a technology that is a spectrum.

I bring this up because it is not a language-nerd observation. It shows up in procurement. When a German company writes a specification for "einen KI-Agenten", the document almost never states how much decision-making is being handed over, because the word does not carry that dimension. The supplier then delivers at whichever level of autonomy suits them, and both sides think they agreed on something.

Three things make agentic AI in the German-speaking market different from the discourse you read in English: the vocabulary is worse, the law is further along, and the adoption numbers are more interesting than the coverage suggests. This piece covers all three.

The Terms, and What Each One Actually Says

The German market runs five terms in parallel, and they are not synonyms even though they get used as though they were.

Agentic AI. Usually left in English. Best understood as an adjective describing degree of self-direction. Correct usage is comparative: more agentic, less agentic, agentic at these three points in the process.

Agentische KI. The literal translation. Grammatically correct, in circulation, and slightly awkward in speech. Useful in written specifications precisely because it keeps the adjective intact and forces the question of how much.

KI-Agent. The concrete system. This is what people say. It refers to the thing, not the property, and it says nothing about autonomy level. A system where a model picks between three prescribed routes is a KI-Agent. So is one that plans its own path across six systems. The term does not distinguish them.

Autonome KI-Systeme. Common in the compliance and IT security world. Emphasises independence of action, which makes it the term risk officers reach for. It also overstates most real deployments, because almost nothing in production is genuinely autonomous.

KI-Mitarbeiter. Literally AI employee. Popular in marketing, and I would avoid it entirely. It implies an employment relationship that does not exist, it invites people to expect judgement the system does not have, and since 2 August 2026 it collides with EU transparency rules if the system is presented to customers as a person.

If you are writing a brief, the useful move is to skip the noun and describe the behaviour. Which decisions does the system make on its own. Which ones need a person. What happens when it gets one wrong. Three sentences that no German label carries, and that determine the entire cost of the project.

What the German Numbers Actually Say

The coverage of AI adoption in Germany oscillates between "the Mittelstand is asleep" and "everything is transforming". The data supports neither.

The AI index for the German Mittelstand, produced by Salesforce together with the Deutscher Mittelstands-Bund and published in March 2026, put the share of mid-sized companies using or testing AI at 51.2 percent, up from 33.1 percent a year earlier. That is a rise of 54 percent in twelve months, and it means the majority tipped over for the first time.

The agent-specific figure is the one worth writing down. AI agents were in use at 16.6 percent of surveyed companies, against 8.7 percent the year before. Nearly doubled. A further 37 percent said they planned to introduce or expand AI during 2026, up from 25 percent at the end of 2024.

Bitkom's survey adds the harder edges. Its 2026 study, based on telephone interviews with 604 German companies of 20 or more employees conducted in the opening weeks of the year, found 41 percent using AI actively, against 17 percent the year before. Another 48 percent were planning or discussing it. Only 11 percent ruled it out.

Then the parts that get quoted less. Only 21 percent of those companies had an AI strategy. A third said AI was costing more than they expected. And the single most-named obstacle, at 41 percent, was uncertainty about data protection.

Read together, the picture is specific and it is not the cliché. German companies are not refusing this technology. They are adopting it faster than the coverage suggests, mostly without a strategy, and the thing slowing them down is not doubt about whether it works. It is not knowing what happens to their data and who is answerable when the system is wrong. Those are reasonable questions. They also happen to be answerable, which is why the companies that get a straight answer move quickly and the ones that get marketing stay stuck.

The Legal Clock Is Further Along Than Most Realise

On 2 August 2026, the transparency obligations under Article 50 of the EU AI Act came into force. They were not deferred.

The operative parts for anyone running an agent are short. Where a person interacts with an AI system, this has to be disclosed, unless it is obvious from the circumstances to a reasonably observant person. Synthetic image, audio and video content has to be marked as artificially generated.

That is a modest requirement and it has one sharp consequence: the agent that introduces itself as a named human colleague is now a compliance problem in the EU, not a clever design choice. If your support agent is called Lisa and customers believe Lisa is a person, you have work to do.

The rest of the regulation moved in the other direction. The Digital Omnibus, agreed politically between Parliament and Council on 7 May 2026, deferred obligations for high-risk systems under Annex III to 2 December 2027, and those covering AI as a safety component in regulated products to 2 August 2028. Rules for general-purpose AI models have applied since August 2025.

The German angle here is that high-risk categories catch more agent deployments than people expect. Recruitment and employment decisions are in there. So is access to essential services, and parts of education. An agent that ranks job applicants sits in a different regulatory world from one that sorts incoming email, even when the two are built from the same components. For the full timeline and what each tier requires, we wrote that up separately when the omnibus landed, and it is the more thorough treatment of the deadlines.

The practical takeaway for anyone deploying now: disclosure is due today, the heavy compliance work has more runway than the original text implied, and the classification of your specific use case matters far more than the technology you built it with.

What Actually Changes When the Agent Works in German

This part gets almost no attention in English-language material, and it is where German deployments genuinely differ.

The address problem has no default. Every German-language system has to decide between Sie and du, and there is no neutral option the way there is in English. Worse, the correct answer is not a company-wide setting. A B2B agent writing to a Geschäftsführer uses Sie. The same company's Instagram bot answering a 24-year-old uses du. Get it wrong in the formal direction and you sound distant. Get it wrong in the informal direction and you sound like you do not know who you are talking to, which in German business correspondence reads as a real error rather than a stylistic one. Every agent we build in German gets this decided explicitly before anything else, because it is not recoverable after the fact.

Text costs more. German compound nouns and longer average word length mean the same content consumes noticeably more tokens than its English equivalent. Since agents are billed by token and an agent loop re-reads its accumulated context on every pass, that difference compounds across a long task rather than staying flat. It does not change what is possible. It does change your cost model, and it is a reason to keep the loop short and the context tight in German deployments specifically.

The variants are real. Swiss German writing does not use ß. Austrian usage differs in vocabulary and in month names. An agent writing to customers across the DACH region either handles that or produces text that reads as slightly foreign in two of its three markets.

Inbound German is messier than outbound. The agent writes clean German. Customers do not. Real incoming messages arrive with dialect, with regional vocabulary, with the compressed grammar people use on WhatsApp, and increasingly from people whose first language is not German. Models handle this well now, but it is worth testing with your own real messages rather than sample text, because the failure mode is not a wrong answer. It is a confident answer to a misread question.

Official language is its own dialect. Anything touching Behörden, insurers or the tax world runs on a formal register with fixed phrasings, and an agent that writes friendly modern German into that context produces documents that look unserious to the recipient. This is a solvable problem and it needs to be solved deliberately.

Where German Deployments Actually Sit

Across what I see in the market and what the surveys report, the German cluster is narrower than the international one and it makes sense.

Customer enquiries that arrive in five different formats and need routing and a first answer. Document work, meaning invoices, delivery notes and orders that mostly follow a pattern and occasionally do not. Research and preparation, where somebody has to gather material from several places before a decision. Monitoring, where something has to be watched and reported without a person checking it every hour.

What is conspicuously rare is the fully autonomous customer-facing agent that closes cases without a human. Partly caution, partly liability, and partly that the German market punishes visible errors harder than the American one does. That is not backwardness. Deployed at level two or three with a human gate, these systems return real time, and they do it without creating a compliance problem the company then has to unwind.

The Position Worth Taking

The vocabulary gap is going to persist, because "agentisch" is not going to catch on and no better word is coming. The way around it is to stop arguing about the label and specify the behaviour instead.

That is how we work. We look at the actual task with the person doing it today, including the exceptions they handle without noticing. We decide explicitly how much the system gets to decide and where a human has to sign off. We test against real cases from the customer's own history rather than invented ones, because real German customer messages are messier than any test set. We settle Sie or du before a line of copy is written. And we host where the customer needs it, including on their own hardware in Germany, because for a good share of the companies in that 41 percent data-protection figure, that is the whole question.

We run our own operation on these agents in three languages daily, German included, and I would apply that test to any supplier in this market. Ask whether they run what they are selling you, in your language, on their own business. The answer sorts the field quickly.

The interesting number is not the 16.6 percent already running agents. It is the 37 percent who said they would start or expand this year. Most of them will get their definition of "KI-Agent" from whoever writes their first proposal. Worth making sure that definition is written by someone who will still be answering for it in a year.

This article was originally published on studiomeyer.io.

Ahrefs API Units: What 1,100 Calls Actually Cost

Matthias | StudioMeyer — Sun, 09 Aug 2026 19:22:59 +0000

On the last morning of my Ahrefs subscription I burned through 400,000 API units before lunch. That was deliberate, since the budget resets monthly and expires with it, so the choice was spend it or lose it. But it produced something I had not expected to find useful: a log of 1,102 calls across those final two days, with the exact unit cost of each one attached.

Ahrefs documents the pricing model in one line. Rows times fields, minimum fifty units per billable request. That is accurate and almost useless for planning, because it tells you nothing about which tool will quietly consume your month. So I measured the 41 I actually used, out of roughly 130 the server exposes.

The short answer is that three tools ate 78 percent of everything, and the free and flat-rate surfaces together returned about a hundred times more rows per unit spent than the three expensive ones.

How the Billing Actually Works

Four mechanics, and you need all four to predict a cost.

Every billable request costs at least fifty units, no matter how little comes back. Some endpoints stop there: the two Site Audit tools charged a flat 50 per call in my log no matter how many rows came back, which is why they end up so cheap per row. The row-priced endpoints, meaning most of Site Explorer and Keywords Explorer, go further and charge per row returned, multiplied by the columns you selected. And some columns cost dramatically more than others: volume, sum_traffic, keyword_difficulty and traffic_domain add roughly ten units per row each, while a middle tier including refdomains adds about five.

The arithmetic that follows is unforgiving. A request for 120 rows with three premium columns selected costs 120 times 31, which is 3,720 units. The same 120 rows without those columns costs around 120. Same query, same shape, a factor of thirty in price, entirely decided by the select parameter.

There is a fifth mechanic that only shows up under stress. During an API incident my usage counter climbed by roughly 24,500 units while not a single row arrived. Those units were later credited back, but the refund landed hours after the fact. So the counter is not trustworthy during an outage, and abandoning a run because the budget appears to be draining can be the wrong call. What is definitely wrong is retrying in a loop while the server returns internal errors.

The Measured Numbers

Sorted by value received, cheapest per row at the top. This is from the _units field of 1,102 real calls, not from documentation.

Tool	Calls	Units	Rows	Units/row
all zero-cost endpoints (Search Console, management, free DR)	214	0	5,940	0
`site-audit-page-explorer`	55	2,750	9,789	0.3
`site-audit-issues`	13	650	2,249	0.3
`keywords-explorer-volume-history`	32	2,362	1,181	2.0
`site-explorer-domain-rating-history`	22	1,366	506	2.7
`site-explorer-pages-history`	22	1,366	471	2.9
`site-explorer-keywords-history`	7	1,232	308	4.0
`site-explorer-refdomains-history`	22	4,098	683	6.0
`site-explorer-anchors`	22	28,971	3,096	9.4
`site-explorer-broken-backlinks`	30	3,305	301	11.0
`serp-overview`	20	8,022	492	16.3
`site-explorer-referring-domains`	37	136,865	8,348	16.4
`site-explorer-all-backlinks`	15	40,375	2,125	19.0
`keywords-explorer-matching-terms`	250	414,542	19,862	20.9
`keywords-explorer-related-terms`	63	27,977	1,287	21.7
`site-explorer-organic-keywords`	70	38,099	1,228	31.0
`site-explorer-top-pages`	29	10,978	298	36.8
`site-explorer-metrics-history`	7	12,628	308	41.0
`keywords-explorer-overview`	6	4,940	110	44.9
`gsc-anonymous-queries`	39	2,088	7	298
all remaining tools	127	16,988	862	n/a
Total	1,102	759,602	59,451

Three Tools Ate Everything

Keyword expansion, referring domains and raw backlinks together consumed 591,782 units, which is 78 percent of the total. Everything else, all 38 remaining tools, came to 167,820.

The single worst line has a cause I can name precisely. I ran keyword expansion at a limit of 250 rows across a batch of seed terms, and a call at that limit cost 5,250 units. At a limit of 50 the same call costs 1,050 and produces the same conclusion, because rows 51 through 250 were fragments and near-duplicates I never looked at again.

Why 250? Because that is the maximum rows per request on the plan I was on. I did not choose it as an analytical decision, I reached for the ceiling because it was there. That turns out to be the most expensive habit available, and it got worse in April when Ahrefs raised the row caps across all tiers. Lite went from 10 rows to 100, Standard from 25 to 250, Advanced from 100 to 500. An explicit limit: 50 in your code is unaffected by that change. What is affected is any call that passes no limit, any call that asks for the current maximum, and any call that used to hit the old cap and now returns up to ten times more rows for up to ten times the price.

The Other Side of the Ledger

Everything tied to a verified project of your own is free or close to it.

Every Search Console endpoint I used cost zero, with one exception I come back to below. Together with the management endpoints and the free domain rating lookup, 214 calls returned 5,940 rows for nothing, and for domains I own those rows are more honest than the paid estimates, because they are measured rather than modelled. Site Audit is nearly as good: both audit endpoints bill a flat 50 units per request regardless of how many rows come back, which worked out to 0.3 units per row across nearly 10,000 pages, with more than twenty technical fields per URL.

Set the two groups next to each other. The free and flat-rate surfaces together returned roughly 18,000 rows for 3,400 units, which is 5.3 rows per unit. The three expensive tools returned 30,000 rows for 592,000 units, or 0.05 rows per unit. That is a ratio of about 103 to 1. The comparison only works for the combined group, because the genuinely free endpoints have no per-unit rate at all.

That ratio is the whole argument. Not "use fewer calls" but "use the other tools first", because in most cases they answer the same question.

Three Places the Common Numbers Are Wrong

Measuring turned up three costs that do not match what gets repeated in guides, including in my own notes before this.

serp-overview is widely quoted at around 180 units per keyword. Across my whole log it averaged 401 units per call, and a separately measured call for a fresh term at limit: 20 came in at about 544. The gap between those two numbers is most likely cached repeats pulling the average down, which is exactly why an average is the wrong number to budget with. Plan a competitive SERP sweep at 544 per term, so twenty terms is around 11,000 units and not the 3,600 the common figure implies.

gsc-anonymous-queries is the worst value in the entire toolkit for a small site, and its name hides that. Everything else with a gsc- prefix is free, so it reads as free. It is not: the documented floor is 50 units per call, and measured it averaged 53.5. Thirty-nine calls returned seven rows in total, because the small sites in my sample never crossed the anonymisation threshold that endpoint exists to reveal. On a large client domain it may well pay for itself. Before using it at scale, spend one call and see whether anything comes back.

site-explorer-metrics-history costs about 1,804 units per call, which makes it one of the most expensive requests in the toolkit, though not the outright worst: site-explorer-referring-domains averaged 3,699 per call. The four individual history endpoints, domain rating, pages, referring domains and keywords, cost between 2 and 6 units per row and together average around 486 units, which is roughly a quarter of the bundled call for nearly the same story.

The Rule That Matters More Than Any of This

Cost discipline is the small lesson. Here is the expensive one.

An early pass of one keyword analysis reported just under half a million reachable monthly searches. It was a real number produced by real API calls, and it was garbage. Keyword expansion drags in fragments and generic words, so single prepositions and bare nouns were sitting in the list being counted as opportunities.

Second attempt, filtered to terms carrying a location: roughly a fifth of the original. Better, still wrong. The top of that list was pure place names, which are travel searches with no commercial intent whatsoever.

Only a double filter produced something defensible. A term had to carry both a location and a signal of what was actually being sold. What survived was about a fifteenth of the first figure, a low five-figure monthly volume across roughly a hundred terms, and it was the first honest number in the sequence.

A volume sum over an unfiltered keyword list is not a number, it is a claim wearing a number's clothing. And it is dangerous precisely because it survives review: it came from an API, it has no rounding, it looks like data. Nobody questions a figure with six digits and no rounding. Before you sum anything, every row has to pass one test. Would a person searching this become a customer? If you cannot answer that per row, do not add the column up.

Six Rules I Would Give My Past Self

Set limit: 50 as the default on keyword expansion and raise it only when a result visibly clipped at the boundary and the extra rows change a decision.

Exhaust the free surfaces first. Search Console for every connected project, the free domain rating lookup, management endpoints, rank tracker. On your own domains these are not the cheap option, they are the better data.

Reach for the flat-rate audit tools before the row-priced ones. Fifty units for up to 250 rows with twenty-plus fields each is the best value in the product by a wide margin.

Strip premium columns unless a decision depends on them. Ten units per row each, and intent columns in particular tell you what the words already say.

Calculate instead of estimating before any block large enough to hurt. My own threshold is 20,000 units, which is arbitrary but forces the arithmetic: rows times one, plus ten per premium column, plus five per middle column. It takes a minute and it is the difference between a planned spend and a surprise.

Put the brake in the script, not in your head. A budget check before each block that aborts below a reserve you set in advance. I wrote mine after the fact, which is exactly the wrong order and the reason this article has such precise numbers in it.

What Happens Now

I did not renew the subscription. The measurement above is part of why: once you can see which surfaces carry the value, it becomes obvious that Search Console covers most of what I needed for my own domains, and that the paid index was earning its keep on exactly two jobs, competitor backlink profiles and search volume for terms I do not rank for yet.

That is a specific conclusion for a specific situation and I would not generalise it. What does generalise is the method. Every Ahrefs response carries its real cost inline. Log that field, group by tool, divide by rows returned, and you will know more about your own usage than any pricing page can tell you. Two days of doing it taught me more than a year of not doing it, and I only did it at the end, when the answer could no longer change what I bought.

If you are still on a plan, do it now.

This article was originally published on studiomeyer.io.