DEV Community: Matthias | StudioMeyer

Claude Fable 5 Is Two Models Wearing One Name

Matthias | StudioMeyer — Tue, 09 Jun 2026 21:43:02 +0000

On June 9, 2026, Anthropic shipped the most capable model it has ever released to the public. The most interesting thing about it is the part that sometimes refuses to talk to you.

Claude Fable 5 is the first model from what Anthropic calls its Mythos class, a tier that now sits above Opus. It launched as a pair. Fable 5 is the public version. Claude Mythos 5 is the same underlying model with its guardrails loosened, and it is not for sale to most of us. It goes only to vetted cyberdefenders and infrastructure providers through a program called Project Glasswing, in collaboration with the US government. Two names, one brain. The thing that separates them is a set of classifiers.

That detail is the whole story, and almost every launch-day write-up buried it under the benchmark chart. So let me start there instead.

One Model, Two Names, One Classifier in Between

Fable 5 ships with three classifiers running alongside it. They watch for requests about offensive cybersecurity, about biology and chemistry that edge toward weapons, and about distillation, which is using the model to train a competitor. When a classifier fires, Fable 5 does not answer. The request gets handed to Claude Opus 4.8, the model that was the top of the public stack until that morning, and Opus answers in Fable's place.

For anyone building on the API, this is not an abstract safety story. It is a response shape you have to handle. A refused request comes back as stop_reason: "refusal" with a normal HTTP 200, not an error, and it tells you which classifier tripped. You can have the API retry on another model with a fallbacks parameter, or do it client side with the SDK middleware. You are not billed for a request that is refused before it generates output.

{
  "stop_reason": "refusal",
  "stop_sequence": null,
  "content": []
}

Anthropic says this is rare. Its early numbers put at least 95 percent of Fable sessions running entirely on Fable's own answers. I believe that for general work. But "rare on average" and "rare for your workload" are different claims. If you build security tooling, parse exploit write-ups, or do biochemistry, you live closer to the classifier's tripwire than the average user, and your effective experience is a quieter, cheaper model with a more expensive bill. Worth knowing before you point a production pipeline at it.

The Benchmark Lead Is Real and Narrower Than It Looks

The headline number is genuine. On SWE-bench Pro, the hard agentic coding benchmark, Fable 5 scores 80.3 percent. Opus 4.8 sits at 69.2, GPT-5.5 at 58.6, and Gemini 3.1 Pro at 54.2. That is an eleven point lead over Anthropic's own previous best and more than twenty over the strongest general model from OpenAI. On Cognition's FrontierCode Diamond it roughly doubles Opus. These are not rounding errors. For long, multi-step coding work, this is the widest gap between frontier models I have seen in a single generation.

Then look at the second number Anthropic published and almost nobody quoted. On SWE-bench Verified, Fable 5 scores 95.0 and Mythos 5 scores 95.5. Same model, half a point apart. The gap is not capability. It is Fable's safety fallback occasionally kicking a coding task over to Opus. That half point is the price of the guardrails, measured.

So the lead is real, but it is concentrated. Agentic coding, tool use, long-context reasoning, finance, vision. Anthropic reports the first score above 90 percent on Hex's analytics suite and the top mark on Hebbia's finance benchmark. As a vendor proof point it cites Stripe running Fable 5 across a 50-million-line Ruby codebase and finishing a migration in a day that it estimated would have taken a team more than two months by hand. Impressive, and also exactly the kind of single-customer number that should make you want to run your own test before you believe it about your codebase.

What It Costs, and the June 22 Catch

Fable 5 costs 10 dollars per million input tokens and 50 per million output. That is exactly double Opus 4.8, which is 5 and 25. It is also less than half what the restricted Mythos Preview cost earlier in the year, so on its own terms the price came down. It carries a 1M token context window and up to 128k output tokens, and it is a Covered Model, which means a 30-day data retention requirement and no zero-retention option. If your contract assumes zero retention, this model does not fit it.

There is a calendar catch that matters more than the sticker price. From launch through June 22, Fable 5 is included at no extra cost on the Pro, Max, Team, and Enterprise plans. From June 23, using it on those plans draws from usage credits. Anthropic frames this as a capacity measure and says it intends to fold Fable back into the flat subscription later, with no date attached. So the free fortnight is a real window to test, and the steady-state cost is a credit meter. Plan accordingly rather than wiring your daily driver to it and getting surprised in two weeks.

The Safeguard Is the Product Decision

Here is the part I keep coming back to. The classifier is not a footnote on a powerful model. It is the product. Anthropic built one model and shipped two postures of it, and the entire public release exists because the safeguards let them feel comfortable handing this much capability to everyone. The benchmark chart is the marketing. The refusal-and-fallback machinery is the actual launch.

That framing also explains the timing that several outlets pointed at. Five days before this release, on June 4, Anthropic published a piece called "When AI Builds Itself," warning that models may be approaching recursive self-improvement and floating a coordinated mechanism for the industry to slow or pause frontier development. Reuters, Scientific American, and others covered it. Then on June 9 the same company shipped the most powerful model the public has ever been able to touch. Critics read that as strategy, a way to invite regulation onto a track Anthropic is winning. Maybe. The more grounded reading is that the two events are the same statement. The slowdown essay and the classifier-gated release are both Anthropic saying the capability is now past the point where you ship it raw. You can find that convincing or self-serving. Either way, the safeguard is no longer a wrapper on the product. It is the shape of the product.

Why the Model Was Rarely Your Bottleneck

Now the unpopular part. For most of the systems people actually run, swapping in Fable 5 will change less than the benchmark gap suggests.

A single-blind study made the rounds earlier this year where the model behind an assistant was swapped without users noticing, and the measured difference in outcomes was not statistically significant. That matches what we see building real systems. Once you are past a capable baseline, and Opus 4.8 and Sonnet 4.6 are well past it, the thing that decides whether your assistant is good is rarely the model tier. It is whether it has the right context in front of it. What it remembers across sessions. How well it retrieves the right document. Whether the tools it calls return clean data. The AI memory systems we build move the needle on those systems far more than a model upgrade does, because the model was answering the wrong question well, not the right question badly.

This is not an argument against Fable 5. It is an argument about where to spend. If your agent forgets the customer between turns, a model that is eleven points better at SWE-bench will forget them eleven points more eloquently. Fix the context first. Then, on the genuinely hard reasoning tasks where you have already done that work, reach for the stronger model and feel the difference. I wrote a longer field guide to the whole Claude lineup if you want the map of which model fits which job.

When to Reach for Fable 5, Opus 4.8, or Sonnet

The honest decision tree is short.

Reach for Fable 5 on the hard agentic work where its lead is real and the task is worth double the token bill. Large refactors across a big codebase, long autonomous tool chains, dense document and financial reasoning, anything where a marginally better answer compounds over many steps. Test it free before June 23, then treat it as the tool you pull out for the hard cases, not the one that runs every request.

Stay on Opus 4.8 as the everyday workhorse for agentic and coding work. It is half the price, it is what Fable falls back to anyway, and on most tasks the difference is small. If your work is security-flavored, Opus is also the more predictable choice, because Fable will route you there mid-task regardless and charge you for the detour.

Stay on Sonnet 4.6 for the high-volume, latency-sensitive, or classification-shaped work where frontier reasoning is wasted. Most of the calls inside a well-built system are this kind. Routing, summarizing, extracting, ranking. Paying frontier prices for them is a common and expensive habit.

Mythos 5, for almost everyone reading this, is not a choice. It is gated to Glasswing partners. The realistic move there is to watch the trusted-access program rather than wait for it.

The launch that matters here is not that Anthropic crossed another benchmark. It is that the frontier now ships with a referee standing between you and the model, deciding in real time which Claude you are allowed to talk to. That is a new default, and it will be the normal shape of every powerful model from here. The teams that win the next year will not be the ones who switched to the highest number on the chart. They will be the ones who already fixed everything the model was never going to fix for them.

Claude in 2026: Models, Apps, Claude Code, and the API

Matthias | StudioMeyer — Fri, 05 Jun 2026 22:55:41 +0000

Most people who use Claude have only seen one tenth of it. They open the chat window, type a question, get an answer, and close the tab. That is Claude the way a phone is a calculator. It works, but it misses the point.

Claude in 2026 is four things wearing one brain. There is the chat product at claude.ai. There is Claude Code, an agent that lives in your terminal and edits real files. There is the developer API that lets you build Claude into your own software. And under all three sits one family of models, available not just from Anthropic but on Amazon, Google, and Microsoft clouds too. The skill that actually matters is not "prompting." It is knowing which of these four surfaces to reach for when. This guide walks all four, with the real numbers, so you can stop guessing.

I run a design and AI studio on Mallorca, and we use every one of these surfaces daily, on our own work and on client systems. What follows is the map I wish someone had handed me.

The model family, in one table

Everything starts with the models. As of June 2026 there are three current ones, and they are genuinely different tools, not just sizes of the same thing.

	Claude Opus 4.8	Claude Sonnet 4.6	Claude Haiku 4.5
API model ID	`claude-opus-4-8`	`claude-sonnet-4-6`	`claude-haiku-4-5`
Best at	hardest reasoning, long agentic coding	speed plus intelligence	fastest, near-frontier
Context window	1M tokens	1M tokens	200K tokens
Max output	128K tokens	64K tokens	64K tokens
Price (input / output per 1M)	$5 / $25	$3 / $15	$1 / $5
SWE-bench Verified	88.6%	79.6%	strong, lower

Opus 4.8 shipped on 28 May 2026 and is the flagship. It scores 88.6% on SWE-bench Verified, the standard benchmark for fixing real GitHub issues, up from 87.6% for Opus 4.7. On Terminal-Bench 2.1 it hits 90.1%. The number Anthropic leaned on hardest at launch was not a benchmark though: Opus 4.8 is roughly four times less likely than its predecessor to let a flaw in its own code pass unremarked. That honesty improvement matters more in practice than a point of SWE-bench, because the failure mode of a coding agent is rarely "can't solve it" and usually "solved it wrong and told you it was fine."

A 1M-token context window means Opus 4.8 and Sonnet 4.6 can hold roughly 555,000 to 750,000 words at once, an entire mid-sized codebase or a stack of contracts. Haiku stays at a still-large 200K. One nuance worth knowing: a big context window does not mean you should fill it. Performance degrades as context fills up, a problem people now call context rot. The window is headroom, not a target.

Pricing scales the way you would expect. Opus is five times the input price of Haiku and five times the output price. The practical rule we use: Haiku for high-volume, well-defined work like classification, extraction, and routing. Sonnet as the everyday workhorse for most chat and coding. Opus when the task is genuinely hard, long-running, or expensive to get wrong. There is also a fast mode on Opus 4.8 at $10 input and $50 output per million tokens, for when latency matters more than cost.

All three read text and images, speak dozens of languages, and run on the Claude API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry. So if your company is locked into AWS or Azure procurement, you can still use the same models through the cloud you already pay for. One caveat: on Microsoft Foundry, Opus 4.8 currently runs with a 200K window rather than the full 1M.

Surface one: claude.ai, the chat product

This is the part everyone knows, and it has quietly grown into a serious workspace. Worth understanding before you pay for anything.

Projects are the feature most people miss. A Project is a container with its own instructions and uploaded knowledge. Drop your brand guide, your API docs, and your tone rules into a Project once, and every conversation inside it inherits that context automatically. For a small business this is the difference between re-explaining your company every morning and never explaining it again.

Artifacts turn a chat into a live workspace. Ask for a small web app, a chart, or a document, and Claude renders it next to the conversation where you can preview and iterate. Artifacts now hold persistent storage up to 20MB each, can call APIs, can talk to external services through MCP, and can refresh with live data when you reopen them. People are shipping genuinely useful internal tools this way without touching a code editor.

Then there is the connective tissue. Connectors are how claude.ai plugs into the outside world, and they run on the Model Context Protocol, the open standard Anthropic released for connecting AI to tools and data. Through MCP, Claude reaches Gmail, Google Drive, Slack, GitHub, Notion, Stripe, and hundreds of other services. As a non-developer you add a connector with a few clicks and Claude can suddenly read your calendar or triage your inbox. This is the same MCP that developers build servers for, which is the elegant part: the protocol is one thing, exposed at every level.

Two more surfaces broaden where Claude lives. Claude in Chrome, in beta for paid plans since late April 2026, puts Claude in a browser side panel where it can see the page and click through it with you. And the Claude desktop app added Cowork, which reached general availability across paid plans in April 2026 and lets Claude read, edit, and create files in a folder you choose, running multi-step work on its own. Voice mode on mobile is now free for everyone.

The plans, with real prices:

Plan	Price	For
Free	$0	trying it, light use
Pro	$20/mo ($17 annual)	individuals, daily use
Max 5x	$100/mo	heavy users, more usage
Max 20x	$200/mo	power users, Claude Code
Team	$25-30/seat/mo	small teams
Enterprise	custom	larger orgs, ~70-seat floor

The honest version: Free is fine to evaluate. Pro is the right tier for one person doing real work. Max exists because the people who run Claude Code all day kept hitting limits, and the higher Max tier and the Team Premium seat are where Claude Code usage is most comfortable.

Surface two: Claude Code, the agent in your terminal

This is the one that changes how work feels, and it is the most misunderstood. Claude Code is not a chatbot in a terminal. Anthropic describes it as an agentic coding tool that reads your codebase, edits files, runs commands, and integrates with your development tools. You tell it what you want in plain language and it does the work across many files, runs the tests, and shows you the diff.

Installing it is one line. On macOS, Linux, or WSL:

curl -fsSL https://claude.ai/install.sh | bash

There is also Homebrew (brew install --cask claude-code) and WinGet for Windows. Then you run claude inside any project and log in. It does not stay in the terminal either. The same engine runs in a VS Code and Cursor extension, JetBrains IDEs, a desktop app with side-by-side sessions, the browser at claude.ai/code, and the iOS app. Your config follows you across all of them.

The single highest-leverage thing in Claude Code is a file called CLAUDE.md. Anthropic's own best-practices doc calls it the agent's constitution. It is a markdown file in your project root that Claude reads at the start of every session. You put your coding standards, your architecture decisions, your preferred libraries, and your review checklist in it, and you stop repeating yourself. On top of that, Claude Code now builds auto memory as it works, saving things like your build command and debugging insights across sessions without you writing them down.

From there it gets powerful in layers. These are the pieces worth knowing by name, because they are the words you use to make Claude configure itself:

MCP servers. The same Model Context Protocol from claude.ai, here in your terminal. claude mcp add wires up a server, and now Claude Code can read your Jira tickets, query your database, or use any tool you give it. Servers are configured per user, per project, or locally, and a shared .mcp.json checks the project's servers into git for the whole team.
Subagents. A subagent is a separate Claude session with its own context window, spawned to handle a noisy or parallelizable task and report back only a summary. The main conversation stays clean. Type /agents to manage them. This is how you run several streams of work at once.
Hooks. Event-driven shell commands that fire deterministically when something happens, like PreToolUse, PostToolUse, or SessionStart. Unlike a prompt, a hook always runs. People use them to auto-format after every edit, block dangerous commands, or re-index a codebase. The newest addition lets a hook call an MCP tool directly, not just a shell command.
Skills. A Skill is a SKILL.md file in .claude/skills/ that packages a repeatable workflow, invoked as /your-skill or automatically when Claude judges it relevant. Unlike a subagent, a Skill runs in the current conversation, no new context, no spawning. Good for codifying a recipe your team reuses.
Plugins. A versioned bundle that ships skills, subagents, slash commands, hooks, output styles, and MCP servers together as one installable unit, shareable through a marketplace. If a Skill is a recipe card, a plugin is the whole cookbook.
Plan mode. Claude reads and proposes a written plan without touching anything. You approve it, then it executes. The discipline this enforces is the whole game.
Checkpoints. Claude Code tracks your session so you can rewind to an earlier state if a change went wrong.

Underneath all of it is a workflow Anthropic recommends and that genuinely works: explore, plan, code, commit. Let Claude read the relevant files first in plan mode, have it write down what it will change and in what order, then let it implement against that plan, then commit with a clear message. Skipping the explore and plan steps is the most common reason a session goes sideways.

And because it follows the Unix philosophy, you can script it. The -p flag runs Claude headless, so you can pipe into it:

git diff main --name-only | claude -p "review these changed files for security issues"

That single pattern, Claude in a pipe, is what turns it from an assistant into infrastructure. We run reviews, translations, and audits this way in CI.

Surface three: the API and the Agent SDK, for builders

When you want Claude inside your own product, you drop to the API. The core is the Messages API, with official SDKs for Python, TypeScript, and Go. A minimal call looks like this:

from anthropic import Anthropic

client = Anthropic()
message = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Summarize this contract."}],
)
print(message.content[0].text)

From that foundation, a handful of features do most of the heavy lifting, and knowing they exist saves you money and rebuilds.

Tool use, also called function calling, lets Claude decide when to call functions you define and with what arguments. It is the basis of every agent. You hand Claude a list of tools with JSON schemas, and it returns structured calls you execute.

Prompt caching is the one that pays for itself. You mark a stable chunk of your prompt, a long system prompt or a big document, with cache_control, and subsequent calls reuse it. Cache reads are charged at roughly ten percent of the normal input rate, so repeated context gets up to ninety percent cheaper. The default cache lives five minutes, with a one-hour option. If you are sending the same instructions on every request and not caching, you are overpaying.

Extended thinking lets the model reason before answering, with a budget_tokens you control:

response = client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    thinking={"type": "enabled", "budget_tokens": 2000},
    messages=[{"role": "user", "content": "Plan a database migration."}],
)

The rest of the platform is a toolbox you pull from as needed. The Batch API runs large jobs asynchronously within 24 hours at a flat 50% discount, ideal for bulk work that is not time-sensitive. The Files API handles documents and images you reference across calls. Citations make Claude point to the exact sentences it used, which is how you build trustworthy, checkable output. There are first-party tools too: a web search tool for current data, a code execution tool that runs Python in the call, and an MCP connector that lets Claude reach any remote MCP server without you writing client code. A memory tool for long-running agents is in public beta.

When you want to build a full agent rather than make single calls, there is the Claude Agent SDK, formerly the Claude Code SDK. It gives you the same agent loop, tool handling, and context management that power Claude Code, in Python and TypeScript, with full control over orchestration and permissions. The mental model: the API is for calls, the Agent SDK is for agents.

Which surface for which job

Put the four together and the decision gets simple.

Reach for claude.ai when a human is in the loop and the work is thinking, writing, analysis, or a quick tool you build in Artifacts. Reach for Claude Code when the work touches files, a codebase, or your local machine, and you want an agent that acts, not just answers. Reach for the API when Claude needs to live inside software you ship to other people. And pick the cloud version, Bedrock, Vertex, or Foundry, when procurement or data residency makes that the path of least resistance.

For the model inside any of those: Haiku for volume, Sonnet for most things, Opus when it is hard or costly to be wrong.

The traps nobody puts on the box

A guide that only lists features is marketing. Here is what actually bites.

The first is confident wrong code. Claude will sometimes invent an API method that sounds right but was renamed two versions ago, or cite a library function that does not exist. The fix is not to trust less in a vague way, it is to give the model current facts. Point it at real documentation, and in Claude Code, give it tools that read your actual code instead of guessing. Opus 4.8 is meaningfully better here, but better is not zero.

The second is context rot. As a session grows long, the model's attention thins out and quality drops. The 1M window invites you to dump everything in, and then the answer gets worse. Keep sessions scoped. Use subagents to push noisy work into separate context. Start fresh when a thread has wandered.

The third is the one to take seriously if you connect Claude to your tools: the lethal trifecta. Security researchers use this term for three conditions that, together, make an agent exploitable. Access to private data, exposure to untrusted content, and a way to send data out. Any one alone is fine. All three at once means a malicious instruction hidden in, say, a web page or an email can make your agent leak what it can see. MCP makes Claude far more capable and, in the same motion, widens this attack surface. The defenses are unglamorous and real: run only MCP servers you trust, use the permission allowlist so the agent cannot run anything it likes, and follow least privilege. Do not give an agent both your secrets and an open door at the same time.

None of these are reasons to avoid Claude. They are the difference between using it well and getting surprised.

Where to start

If you have never gone past the chat window, do three things this week. Make one Project and load it with your real context. Install Claude Code and write a ten-line CLAUDE.md for one repo. Add one MCP connector to something you actually use. That is the whole arc of this guide in three moves, from chat to agent to connected.

The reason any of this matters for a business is that the gap between islands of tools is where time leaks, and Claude across these four surfaces is, more than anything, a way to close those gaps. We connect Claude to client systems through MCP for exactly that, and the StudioMeyer Memory server is our own answer to the part this guide keeps circling, giving Claude a memory that survives between sessions.

If you want the terminal side on its own, our walkthrough on setting up Claude Code without the jargon is the natural next read.

Claude is no longer one window. Learn the four surfaces and the model stops being a clever toy and starts being something you build on.

How AI Citations Actually Work, From Query to Footnote

Matthias | StudioMeyer — Thu, 04 Jun 2026 21:18:32 +0000

Ask ChatGPT, Perplexity and Gemini the same question and on more than a third of queries you get three different lists of sources. Same web, same question, three separate verdicts on who is worth citing. That divergence is the clearest window we have into how AI citations actually work, and almost everything written about the topic skips the mechanism and jumps straight to optimization tips. This is the mechanism.

An AI citation looks like a small thing. A number in superscript, a little source card under a paragraph, a link with utm_source=chatgpt.com stapled to the end. Behind that small thing sits a pipeline that runs in the second between your question and the answer, and it has almost nothing in common with how Google ranked pages for the last twenty years. Once you can see the pipeline, the topic stops being mystical. You can predict, fairly well, why a model cited one page and ignored another that was objectively better written.

A Citation Is Not the Model Knowing You

There are two completely different ways a language model can produce a sentence about your business. The first is parametric memory, the knowledge baked into its weights during training. If your company was in the training data, the model might "know" you, but it cannot point at a source, because it never stored a URL, only a statistical blur of text it absorbed months earlier. The second way is real-time retrieval. The system goes out, fetches live documents, and writes the answer using those documents as evidence. A citation is only ever the second thing.

This is Retrieval-Augmented Generation, usually shortened to RAG, and it is the architecture under almost every AI answer that shows sources. The model retrieves relevant documents first, then generates the answer grounded in them. The difference between the two paths is the difference between "the model has a vague impression of you" and "the model can quote you and link to you." One analysis put across more than 680 million AI citations under the microscope in 2026, and the pattern holds everywhere: the cited answers are the grounded ones, not the remembered ones.

That distinction reframes the whole problem. Getting into the training data is slow, fuzzy and mostly out of your hands. Getting retrieved is a live, mechanical event that happens every time someone asks a relevant question, and it follows rules you can actually reason about.

The Pipeline Behind a Single Answer

When you ask an AI search tool a question, five things happen in quick succession. They are worth walking through, because each stage filters out most of the web before the next one even starts.

First, query interpretation. Your messy human question gets rewritten into one or several short retrieval queries. These are called grounding queries, and they are the literal terms the system will actually search for. "Who is the best estate agent for rural fincas near Campos" might become three clean queries about regions, property types and agencies.

Second, retrieval. The system runs those queries against an index using hybrid search, combining old-school keyword matching (BM25) with dense vector embeddings that capture meaning rather than exact words. Where the index comes from differs by engine. Perplexity crawls the open web continuously. ChatGPT leans heavily on Bing's index. Each one is searching a different map of the internet.

Third, re-ranking. Retrieval returns far too many candidates, so a re-ranker scores them and keeps a handful. Perplexity is documented as running a three-tier reranker for this. Hundreds of pages collapse to maybe five or eight.

Fourth, extraction. This is the stage most people miss. The system does not read your whole page. It pulls the specific passages that answer the sub-question, the chunks, and discards the rest. Fifth, synthesis and the citation decision: the model writes the answer constrained by those passages, then attaches each source to the spans its passage supported.

The consequence of stage four is the single most important fact about AI citations. Engines cite passages, not pages. They do not rank your site or judge its overall quality the way Google does. They lift the paragraph that cleanly answered one narrow question. A page can sit at position one on Google and never get cited, because the answer was smeared across five paragraphs and no single chunk stood on its own. The numbers bear this out: only about 44 percent of pages ranking in Google's top ten show up in AI citations at all. It is a different game with a different scoreboard.

Grounding Is the Part That Makes Citations Trustworthy

Grounding is the mechanism that separates a model's opinion from a model's evidence. After the draft answer is generated, good systems run span-level verification. Each assertion in the answer gets matched back against the retrieved passages. The system either confirms the passage supports the claim, flags the claim as unverified, or catches a contradiction between the claim and the source. It is a fact-checking layer sitting between the model's generation and your screen.

On top of that runs corroboration. The engine cross-references a claim against other authoritative sources across the web. If several trusted sources state the same fact in similar language, the engine treats it as verified and is comfortable citing it. A lone page making an unusual claim that nothing else echoes is a weak and risky citation candidate, even if the claim happens to be true.

This is why citations reduce hallucination instead of causing it. The answer is tethered to text the system genuinely pulled and checked. It is also why the structure of your content matters more than its prose polish. The pipeline is not admiring your writing. It is checking whether a passage supports a specific claim, and whether the rest of the web backs it up.

Four Engines, Four Different Minds

The reason three assistants give three different source lists is that they are running different retrieval strategies on different indexes with different biases. The broad shapes in 2026 look like this.

Perplexity is retrieval-first. It searches almost every query, crawls the web continuously, and cites by default with numbered inline sources. It pulls nearly three times more sources per answer than ChatGPT, leans unusually hard on Reddit (close to 47 percent of its top citations), and reacts to structural changes on a page within two to seven days, the fastest of the bunch. Schema markup barely moves it.

ChatGPT is parametric by default. It answers from training unless a query trips its search behavior, at which point it retrieves through Bing's index. Its training left it biased toward consensus and encyclopedic sources, which is why Wikipedia looms so large in its citations. It cites a smaller share of what it finds, and with 800 million weekly users, being invisible there is the most expensive kind of invisible. Since June 2025 it tags citation links with utm_source=chatgpt.com, which at least makes the traffic measurable.

Claude is the conservative one. It leans on its training and a supplied corpus, and only browses when given tools. When it does cite, it rewards depth and clear structure, roughly 30 percent more likely to cite a well-organized, bullet-pointed page, and it is the strictest engine on freshness. On time-sensitive topics it discounts content whose last-modified date is more than a year old. Gemini and Google AI Overviews sit on Google's own Search index, skew toward brand and entity signals, and show their sources beneath the summary rather than inline.

The practical upshot is divergence. Across the three engines, somewhere between 35 and 40 percent of queries return source sets that barely overlap. ChatGPT and Perplexity have been measured sharing only around 11 percent of their cited domains. Treat AI visibility as one thing and you are optimizing for one engine while three others quietly ignore you.

Why Some Pages Get Pulled In and Most Do Not

Once the pipeline is clear, the reasons certain pages keep getting cited stop looking like SEO folklore and start looking like plumbing.

Retrievability comes first, and it is the most common silent failure. An engine cannot cite a page its crawler cannot reach. Each one runs its own agent: OAI-SearchBot for ChatGPT search, ClaudeBot and Claude-User for Anthropic, PerplexityBot, Google-Extended for Gemini. Block one in your robots.txt and that engine is simply blind to you, no matter how strong the content is. Plenty of excellent pages are uncitable for this one boring reason.

Extractability comes next. Because the pipeline lifts passages, content that answers a sub-question cleanly in a single place gets extracted, and content where the answer is diffused across half a page does not. That is the real reason answer-first writing, clear headings, tables and direct definitions correlate with citations. They are not magic ranking signals. They are mechanically easier to chunk and lift.

Then corroboration and original data. A claim echoed across the web in consistent language is safe to cite, which is why brand presence on Reddit, Wikipedia, news and review sites moves citations more than any on-page tweak, especially on ChatGPT. The flip side is just as useful: publish a number nobody else has and you become the only possible source for it. Original research has been measured at roughly 3.7 times more likely to be cited, and structured data markup at about 2.1 times. Freshness closes the loop, since some engines, Claude most of all, quietly discount stale timestamps.

None of this is a trick. It is the shape of the pipeline showing through. The machine rewards content that is reachable, liftable, corroborated and current, because those are the four things the pipeline literally checks.

The Next Layer: From Reading You to Acting on You

Citations are about whether a model can read and reference you. The frontier moving through 2026 is whether an agent can do something with you, and a few standards are quietly building that bridge.

The lightest is llms.txt, a markdown file at the root of your site that lists your important pages with short descriptions, a kind of sitemap written for models instead of crawlers. It reduces the work an engine has to do to figure out what matters, and it is already in use by Cloudflare, Stripe and hundreds of thousands of other sites. You can read the llms.txt spec in a couple of minutes. Schema.org markup does a related job at the data level, handing the parser structured facts instead of prose it has to interpret.

The bigger shift is the Model Context Protocol, an open standard from Anthropic that lets an AI app connect straight to a live data source or tool instead of scraping text off a page. Instead of guessing your prices from a cached paragraph, a model can query them directly. The common shorthand is "USB-C for AI." One step further sits the idea behind WebMCP and agents.json, where a site publishes callable tools, book a slot, check availability, request a quote, that an agent can invoke directly. The page stops being something to read and becomes something to operate.

The trajectory is straightforward. It runs from "is my content in the retrieval index" to "can an agent transact with my business without a human ever opening the site." Citations are the first rung on that ladder, which is exactly why they are worth understanding properly rather than chasing with checklists.

What This Actually Means

Strip it all back and an AI citation is the visible end of a retrieval, grounding and verification pipeline. It is not proof the model knows you, and it has surprisingly little to do with how you rank on Google. The pages that get cited are the ones the pipeline can reach, lift cleanly, corroborate against the rest of the web, and trust as current.

My prediction is that the gap between "ranks well on Google" and "gets cited by AI" keeps widening, because the two measure genuinely different things, and a lot of businesses are about to discover their hard-won SEO does not carry over the way they assumed. The ones who treat AI visibility as its own discipline, with its own mechanics and its own measurement, will pull ahead while everyone else waits for the citations to show up on their own. That discipline has a name, Generative Engine Optimization, and the first half of doing it well is simply understanding the pipeline you are optimizing for.

n8n, LangGraph, Temporal: Automation Done Right

Matthias | StudioMeyer — Mon, 01 Jun 2026 13:57:11 +0000

Everyone can wire up n8n. Almost nobody can tell you where n8n stops. That gap is the entire job. Real automation is three layers, not one tool, and the layer most people build is the easy third. We run all three in production, in our own systems and for clients, and the value was never the part everyone already has.

n8n had a strange year. In October 2025 the company raised 180 million dollars and crossed a 2.5 billion dollar valuation, up from 300 million four months earlier. Around 230,000 people now run it, three quarters of them using the AI nodes. Every second automation post on LinkedIn is an n8n canvas with a few boxes and an arrow. The tool earned the hype. It is genuinely good, it is self-hostable, and it connects to almost everything.

And that is exactly where most automation projects quietly stop. Someone sets up n8n, wires a webhook to a Slack message, calls it an automation strategy, and moves on. It works until the workflow has to make a judgment call, or until it has to survive four days and a server restart without losing its place. Then the visual canvas runs out of road, and the people who only know the canvas run out with it.

What Automation Actually Needs

Strip away the tools and there are three jobs underneath every serious automation. They are different problems, and a tool that does one well usually does the other two badly.

The first job is connecting things. A signup comes in, a record goes into the CRM, a welcome mail goes out, a notification lands on someone's phone. No thinking required, just reliable plumbing between systems that were never designed to talk to each other. This is the bulk of automation by volume, and it is the job n8n was built for.

The second job is making a judgment call. The workflow has to read something ambiguous, decide what it means, and pick the next step based on that decision. An email arrives and the system has to judge whether it is a real lead or noise, then route accordingly. A draft gets reviewed and the system has to decide whether it is good enough to ship or needs another pass. This is not plumbing. This is reasoning, and it needs a different kind of tool.

The third job is surviving over time. Some workflows run for hours or days. They wait for a human to approve something. They call six external services, any of which can fail, and a failure halfway through must not corrupt the other five. If the machine reboots at step four of seven, the work has to resume from step four, not start over. This is durability, and it is the hardest of the three to fake.

These three jobs are orthogonal. A tool that tries to be all three at once ends up mediocre at each. A stack that picks the right specialist for each layer beats the all-in-one every time. Our three specialists are n8n, LangGraph, and Temporal.

n8n: The Layer Everyone Already Has

n8n is the connecting layer, and for that job it is excellent. Four hundred plus pre-built integrations, a visual canvas a non-engineer can actually read, self-hosting in under half an hour. We run it as the automation hub for the unglamorous work that keeps a business moving. A signup webhook that creates a CRM lead and fires a welcome mail. A new blog post that fans out into draft social posts. A scheduled health check that pings a row of services and alerts a channel when one goes quiet. An inbound email that gets parsed for intent before it touches a human.

This is real value and I want to be clear about it. n8n is not a toy and it is not Zapier for power users. It is a proper, fair-licensed, self-hostable orchestration platform, and for connecting systems it is often the fastest correct answer. If a client needs their ops team to edit a workflow without a deployment cycle, the visual canvas wins on its own merits.

The honesty starts when you look at what n8n is not. It runs steps in sequence by default, so genuine parallel work with shared state gets fragile fast. People report merge nodes that fail a few percent of the time on race conditions that simply do not exist in controlled code. It is not a state machine with deterministic replay, so a crash mid-run does not cleanly resume. There is no first-class testing. And the moment a workflow needs anything unusual, you drop into a Code node, and the Code node is where n8n workflows silently accumulate the technical debt nobody put on the canvas. None of this is a flaw. It is just the edge of the layer. The mistake is not using n8n. The mistake is believing the canvas is the whole map.

LangGraph: When the Workflow Has to Think

When a workflow has to reason instead of just route, we reach for LangGraph. It is a code-first framework from the LangChain team that models a workflow as a graph of steps where the language model, not a fixed diagram, decides what happens next. Since LangChain 1.0 shipped, LangChain's own agents run on LangGraph underneath, and the production user list reads like a who's who, with Uber, LinkedIn, Klarna, and Replit on it.

The two features that earn its place are state and pausing. State means the workflow remembers where it is. Every step gets checkpointed into a database, so a crash at step three resumes at step three rather than burning the whole run. Pausing means the workflow can stop in the middle, wait for a human to approve or correct something, and then continue with that answer folded in. In LangGraph this is one primitive, not a custom-built side system.

A concrete shape we run on it: a multi-step agent pipeline where one step drafts a plan, the next builds against it, a third reviews the result, and a fourth tests it, with an approval gate that pauses the whole thing for a human whenever the review comes back uncertain. That is reasoning plus checkpoints plus human-in-the-loop, the exact combination LangGraph exists for and the exact combination n8n's canvas struggles to express without nested sub-workflows and polling hacks.

The trade-off is real and worth saying out loud. LangGraph is overkill for a workflow that just calls a model and posts the result somewhere. Reach for it too early and you have written two hundred lines of framework code where fifty lines of plain logic would have read more clearly. It also carries a proprietary license, which is a lock-in risk we manage deliberately rather than ignore. The discipline is to use it only where reasoning and resume genuinely pay for the added weight.

Temporal: When the Workflow Cannot Be Allowed to Die

The third layer is the one almost nobody in the n8n crowd has even heard of, and it is the one that separates a hobby setup from infrastructure. Temporal is a durable execution engine. It records every step of a workflow as an event history, so when a server crashes it spins up a fresh worker, replays the history back to the exact state before the crash, and carries on as if nothing happened. Workflows can run for days or years. It is open source under the MIT license, and it has quietly become the standard for durable agent execution. OpenAI runs Codex on it in production, for agents that wait days for human approval and survive restarts without losing their place.

What this unlocks is the class of workflow that touches the real world and cannot afford to be half-done. A billing lifecycle where a subscription renews, a payment is taken, and a refund has to roll back a chain of side effects cleanly if one step fails. A customer onboarding that runs over several days with timers and waits built in. A recurring job that aggregates work across many sources and must complete reliably every single time. These are sagas, long-running transactions with compensation when something breaks, and they are exactly what a visual canvas was never meant to hold.

There is a clean rule of thumb the field has converged on, and we use it. If a task is a single read-only step under thirty seconds, you do not need any of this. The moment a workflow makes three or more external calls, waits hours for an event, or fires irreversible actions like payments or deletions, durability stops being optional. We publish a set of durable workflow templates as open source so the pattern is not a black box, available at github.com/studiomeyer-io/temporal-memory-workflows. The cost of Temporal is operational overhead and a few rules about how you write the code, which is exactly why you do not reach for it below the threshold.

How the Three Layers Fit Together

The trap is to ask which tool wins. None of them wins, because they are not playing the same game. n8n connects systems and triggers things. LangGraph reasons and pauses for people. Temporal guarantees that long, important work finishes. In a mature setup they stack: n8n catches the event and does the glue, hands the thinking to a LangGraph agent, and wraps anything long-running or irreversible in a Temporal workflow so a crash is a non-event. The observability side of that same architecture, watching what every layer actually did, is its own discipline that we covered separately in our piece on the agent observability stack.

The single most important habit across all three is keeping your actual business logic out of the framework. The rules of your domain live in plain, tested code that any of these tools merely calls. Do that and switching a workflow from one layer to another is a day of work, not a rewrite, because the part that matters never depended on the tool. Skip it and you marry whichever canvas you started on, which is how teams end up trapped inside an n8n workflow that should have graduated to code a year ago.

Setup Is a Commodity. Architecture Is Not.

Here is the part the market gets backwards. Setting up n8n is a commodity now. There are thousands of people who will draw you a canvas, and the price of that work is falling because the tool made it easy, which was the whole point. If all you buy is the n8n setup, you bought the layer that was already the cheapest to build.

The value is in the two decisions nobody sells you. First, knowing which of the three layers a given problem actually needs, and having the judgment to resist both failure modes: cramming a reasoning problem into an n8n Code node until it rots, and over-engineering a fifty-line job into a durable workflow it never needed. Second, building the boundary so cleanly that the choice stays cheap to revisit. That is architecture, and it does not show up on a canvas screenshot.

There is one more thing worth being honest about. What runs our own internal systems is deliberately pragmatic, tuned to be good enough for a solo operation that knows its own edges. A client engagement gets the other gear entirely, the same three layers but with the hardening, the governance gates before risky actions, the observability, and the testing that a system someone else depends on actually requires. Knowing the difference between good-enough-for-us and right-for-a-client is itself part of mastering the stack. Anyone can run the tools. Knowing how far to take them is the work.

So the next time you see an automation pitch that begins and ends with n8n, the question to ask is not whether the canvas is nice. It is what happens at the two edges the canvas does not show, when the workflow has to think and when it has to survive. If you want that whole stack designed properly rather than just the easy third, [that is the conversation we have]

(https://studiomeyer.io/en/services/automation).

The Other Web Design and AI Agency on Mallorca

Matthias | StudioMeyer — Sat, 30 May 2026 22:51:00 +0000

There are good web design agencies on Mallorca. Plenty of them build sites that look great, and we are not here to talk anyone down. But two things stand out when we look at how most of them work. The first is price. Good work on the island tends to be expensive, and it tends to stay that way. The second is what sits under the hood. A large share of those sites run on WordPress, which usually means a stack of plugins, and plugins are where the slow costs hide. Each one is a door someone has to keep locked, a security update waiting to be missed, and very often a yearly licence that quietly adds up. A site that looked affordable at launch can cost more every year just to stay safe and online.

Then there is the AI part, where a lot of agencies hang a chatbot subscription off the side and call it transformation. We approach both of those differently, and that is what this post is about.

We are a small studio based in Palma. We work with owner run companies and mid sized businesses, on the island and across the German speaking market. Most of the people we work with are not technical and have no interest in becoming technical. They want a website that works, they want to show up when a customer asks ChatGPT or Claude for a recommendation, and they want the whole thing to run without turning into a second job. What sets us apart is not a louder promise. It is that we wrote the software underneath ourselves. So when a client asks for something unusual, the answer is usually yes instead of "the system does not allow that."

We do a lot, but everything we sell fits into three areas. We build websites. We connect businesses to AI. And we set up AI systems that take real work off your desk. Here is what each one actually contains, in plain language.

Websites You Are Never Locked Out Of

The first reason most clients come to us is a website. We build sites that load fast, look like they belong to a serious business, and can be read by both people and the AI systems that increasingly sit between your customer and your front door. That part is the baseline. The more interesting question is what happens after launch, because that is where most businesses quietly get stuck with their old agency.

A lot of our clients want us to handle everything. They never want to log in again. They send a short email when the opening hours change and it is done by the afternoon. We do exactly that. Full care, no backend for you to learn, we keep the site current and you get on with running your business.

But some businesses change things constantly. A restaurant with a menu that moves with the season. A real estate office adding and removing listings every week. A shop with offers that change every Friday. For them, depending on an agency for every small edit is a trap, and a slow one. So we built our own content system, the StudioMeyer CMS, that lets you change the things that move without calling us and without fighting a bloated backend. Because the system is ours, there is no row of plugins renewing every year and no plugin security hole waiting to be patched, which is a big part of what makes a WordPress site quietly expensive over time. It shows you only what you actually need to edit and nothing else, which is the opposite of how most website admin panels feel.

On top of that we have two more ways in, depending on how you like to work. There is a Telegram bot: you send a message from your phone, something like "change the Tuesday special to grilled sea bass," and the site updates itself. No login, no laptop, no waiting for office hours. And on request we build you a small connector so you can edit your own website straight out of ChatGPT or Claude, just by asking in normal words. The point of all three options is the same, and it is the most important thing we can tell a website client: you are never locked out of your own site and never held hostage by the people who built it. If you want us to handle everything, we do. If you want to control the parts that change daily, you can, through whichever tool feels natural. That choice is the actual product, and you can see how we package it on our web design page.

An AI Connector Between Your Business and ChatGPT

This is the part that surprises people the most. When your customer opens ChatGPT or Claude today and asks about your business, the answer they get is whatever the AI guessed from the open internet. Usually generic, sometimes outdated, occasionally about a competitor. The AI connector changes that. It plugs your actual business into those AI tools, so the answer comes from your knowledge, your data and your way of doing things, not from the model's general training.

In everyday terms, a guest can ask an AI assistant whether you have a table free on Saturday and get a real answer. A customer can ask what your price would be for their specific situation and get your number, not an invented one. Someone can start a booking, a request or an order by simply describing what they want, and the right thing happens on your side. We will not pretend there is a fixed list of features here, because there is not. Every business wants something slightly different, and being able to say yes to that is the whole point. Your knowledge, your data, your actions, your access, shaped around your company rather than squeezed into a template.

There is almost no technical ceiling to this. We can connect the systems you already run, a custom backend, the software your team lives in all day, and make the whole thing usable through a normal AI chat. The honest limit is not the technology. The limit is what you are comfortable making available, and that is a conversation we take seriously. Data protection is not a checkbox for us. With every client we work out exactly what the AI is allowed to see, where the data is stored, and what stays private, before anything goes live. For businesses serving German speaking customers that part is not optional, and we treat it as the real design work rather than an afterthought. So the honest way to picture the connector is this: whatever you can describe, we can almost certainly connect, and the serious part of the job is deciding together where the line sits. We explain the idea in more depth on our AI connector page.

AI Systems Set Up Around the Way You Already Work

The third area is setting up AI systems that do actual work. The simplest version is what we call a KI-Mitarbeiter, an AI staffer. It answers incoming questions, pre qualifies enquiries before they reach a person, summarises long email threads, and hands the important things over at the right moment. It does not get tired and it does not drop the ball at eleven at night.

The part worth understanding is what happens when you already have software you like. Most agencies, when they sell you AI, want to replace your tools with theirs. We do the opposite. If you are happy with your booking system, your CRM, your shop or your phone setup, you keep it. We connect a small server to it so the AI can reach in and work with what is already there. Your existing app gets an AI layer on top instead of a painful migration that takes months and annoys your whole team.

A few concrete shapes this takes, without naming anyone. A CRM you usually open in a browser becomes something you can also drive from a chat: "show me everyone I have not followed up with this week," and it answers. A phone setup gains pre qualification and a written summary of every call, without changing the phone system itself. A piece of software your team has used for years suddenly understands plain language requests, because we taught the AI how to speak to it. You did not switch anything. You simply got an extension. For a business that has finally settled into tools that work, that distinction is everything.

What the Three Have in Common

Look back at the three areas and the same idea runs through all of them. A website you can actually control. An AI connection shaped around your own data instead of the open internet. AI systems that wrap around the tools you already use instead of replacing them. None of that is possible if an agency is only reselling what some software vendor decided to ship. It is possible because we build the pieces ourselves and fit them to the business in front of us. That is also why, across all three, the answer to "can you also make it do this" is usually yes rather than a polite no.

That is what we mean when we say we are the other kind of agency on Mallorca. Not louder, not cheaper, not heavier on buzzwords. Just a studio that wrote its own tools, sits on the same island you do, and starts every project with a real conversation instead of a fixed package. If any of the three areas sounds like something your business needs, the first call is free, and it is a person who picks up, not a funnel. You can find us at studiomeyer.io.

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

Five Doors into the Same Workshop, the StudioMeyer Ecosystem

Matthias | StudioMeyer — Sat, 30 May 2026 16:01:37 +0000

In the same week last month I had five conversations that ended in five different questions. A boutique hotel owner in Sóller wanted a website that ChatGPT would recommend when guests ask for honest Mallorca tips. A solo founder in Berlin wanted to learn how to be an AI operator without paying a thousand euros up front. A management team in Hamburg wanted four days off the grid to actually build their first agent fleet together. A senior engineer in San Francisco wanted to read the source of our MCP memory server and lift the parts that fit his stack. A multi-agent researcher in Tokyo wanted to watch several Claude instances live out a simulated life on Mallorca and see who survives.

Five people, five questions, same week, same studio. A single homepage cannot answer all five well. We tried for about a year. Then we split the studio into five domains, each with its own voice, its own pricing, its own audience, its own language. They share one office, one team, one knowledge graph, and one Google Business Profile. From the outside they look like five independent projects. Under the hood they are five doors into the same workshop.

This post is the map.

Why five surfaces instead of one

The temptation when you do many things is to put them on one site, behind one menu, under one brand statement. We tried. It produces a homepage that is either too generic to convince the boutique hotel owner or too technical to make sense to the career changer. Every paragraph apologises to a different reader. Conversion drops on both ends.

The argument for splitting is the inverse. A site that is built for one audience can speak to that audience without compromise. The hotel owner gets a clean B2B page with prices and a calendar link. The career changer gets a learning platform with no signup wall and a Discord. The Hamburg team gets photos of a finca and a four-day program. The engineer gets a repo grid and architecture diagrams. The researcher gets a live feed of nine AI citizens deciding what to do next.

What you lose by splitting is brand consolidation. What you gain is conversion clarity. We made the trade because at the scale of a single founder studio, a confused visitor on the wrong page costs more than a fragmented brand. The link layer between the five domains, Schema.org markup with parentOrganization and subOrganization pointing in both directions, plus one shared Google Business Profile, makes sure ChatGPT, Perplexity, Bing Copilot and Google AI Mode read the cluster as one entity. Crawlers see five connected surfaces. Visitors see exactly the door they came for.

studiomeyer.io, the studio itself

studiomeyer.io is the B2B studio. Founded 2025, this is where the actual paying work happens. We build websites, AI systems and custom MCP servers for small and mid sized businesses and for agencies that need a whitelabel back office.

Pricing is on the site and stays the same whether you find us through a referral or cold. Webdesign Starter is 199 euros per month, Professional 299, Individual 499 with a 999 euro setup fee or 6,500 euros one off. AI systems are 399 a month plus 999 setup. The first call is always free, booked through Cal.com, taken either at our cowork office at Avinguda de Joan Miró 138 in Palma or over video.

The audience is owners and managing directors who want one person to handle design plus AI integration without juggling three vendors. Hospitality and real estate on Mallorca, agencies in the DACH region, and a growing tail of clients in Hamburg, Berlin, Munich, Zurich and Vienna. The one proof point we lead with is the Bing Copilot citation count. As of May 2026 our own site gets cited about 4,500 times per month by Bing Copilot. The number lives in lib/proof-metrics.json on the site itself and updates from a live Bing Webmaster Tools screenshot, not from a marketing slide. If you want to see the dashboard before you talk to us, ask, and we will share it.

What studiomeyer.io is not: a self serve product, a tool you click through, or a quick fix shop. Every project starts with a conversation. Every site is built for one specific business.

studiomeyer.academy, the open classroom

studiomeyer.academy is the free learning platform. We launched it in April 2026 and pivoted away from the original Pro tier in the same month. It has been completely free since then. No paywall, no signup to read, no hidden upsell. You can land on it, finish a lesson, and never give us an email address.

The platform is built as six levels. Level 1 explains what LLMs actually do, how to spot hallucinations, and how prompting works. Level 2 covers productive day to day use of Claude, ChatGPT and Gemini. Level 3 introduces no code automation with Zapier and n8n. Level 4 is where it gets interesting, memory first workflows with the Model Context Protocol, hooks and skills. Level 5 covers multi agent systems, the CEO worker pattern, critic and research and analyst agents, cross agent memory. Level 6 is full stack AI systems, building, deploying and selling your own MCP server.

The content lives in three languages, German, English and Spanish. Beyond the levels we ship a stack of recipes with step by step validators, playbooks for switching between Claude, Cursor and Codex, and 48 interlinked concept pages that explain individual terms. There is also an npm package called mcp-academy that turns the academy into an MCP server with 23 learning tools. You install it once, point Claude Desktop or Cursor or Codex at it, and the academy becomes a tutor that lives inside your editor.

The audience is career changers, job seekers and solo founders who want to become AI operators without paying for a bootcamp. The Discord is small, on purpose, and Matthias reads along. It is not a sales channel.

aifinca.es, the four day retreat

aifinca.es is the retreat format. Founded in 2026, this is where we run small group workshops on a finca in the Mallorcan interior, away from the tourist coast. The tagline is "KI lernen wo andere Urlaub machen" which translates roughly to learning AI in a place other people come to vacation. The hook line is "operator depth instead of conference bingo".

There are four formats. KI im Alltag for solo learners building their own assistant, four to eight seats. KI fürs Business for management teams building an agent fleet, capped at four. Team KI-ready for full teams who bring their work and leave with a working system, capped at six. And Einzelunterricht, full one on one custom format.

Each retreat runs four consecutive work days. Accommodation and meals are included. The fincas we work with sit in the hinterland, stone walls and olive trees and long wooden tables under pergolas. Pool and quiet when you need them, real conversation when you want them. The location rotates by season and program. Pricing is not on the site yet because the format is genuinely custom per group and we have not found a single price that does not lie about one of the four formats. So it is "auf Anfrage", on request, and we quote per group.

This is the format for people who do not learn well on Zoom and do not get a return on a conference ticket. It is also the format that lets us teach the deep operator work that does not fit into a written lesson.

matthiasmeyer.tech, the workshop floor

matthiasmeyer.tech is my personal open source hub. Founded in 2025, it is where the building blocks I use in studio projects get published under MIT before anyone else sees them. The framing on the site is simple: I build the MCP servers, memory engines, agent patterns and security layers I need for my own AI stack. Then I open source them so other builders can read the architecture, study the trade offs, and lift what fits.

The hero of the site is a 3D force graph of all the repos. Nodes are projects, edges are which one uses or extends which. You can drag a node, hover for details, click through to GitHub. The eight cornerstone projects are Local Memory MCP (persistent local memory for Claude, Cursor and Codex, SQLite plus FTS5 plus a knowledge graph, no cloud, one command to install), Personal Suite MCP (forty nine local first productivity tools across six modules), MCP Video (cinema grade video production via MCP, eight tools on ffmpeg and Playwright), Agent Fleet (multi agent orchestration for Claude Code), AI Shield (LLM security toolkit covering injection, memory canary and circuit breakers), Darwin Agents (self evolving prompts with GEPA style reflective optimisation), MCP Armor (a drop in Rust sidecar for MCP servers), and n8n Templates (production patterns with cross session memory).

Plus a long tail of secondary projects, the MeetMyAgent SDK, an AI Shield Python port, an MCP Stdio Shellguard, the MCP Spec Migrator 2025-11-25, MCP Tenant Pair, MCP Hook Conformance and several more. 32 MIT licensed repos in the studiomeyer-io GitHub organisation in total. All with docs. All with tests. All written for builders who want to read code, not buy a SaaS.

If studiomeyer.io is the storefront, matthiasmeyer.tech is the workshop floor with the lights on.

meetmyagent.io, the research lab

meetmyagent.io is the research arm. Founded in 2026, this is where we run the kind of experiment that does not yet have a customer. The first live experiment is Polis: a fictional Mediterranean town on Mallorca where AI citizens live over time. Different model tiers side by side, each citizen with their own job, their own money, decisions that build on each other. We watch how long term decision making differs across model tiers in a way that single shot benchmarks cannot show.

The second live experiment is Chess. Here we run different chess experiments to measure how tools, memory and prompt evolution change LLM agent behavior over time. AI agents play against each other, every move goes through a reasoning pipeline with clickable stations, all tool calls and decisions are open to inspect.

There is a separate angle to meetmyagent.io too. It is positioned as an agent marketplace where AI agents can register, post, bid on jobs and build reputation on behalf of their humans. The operating principle is "bots draft, humans approve". Every action gets a human sign off. The marketplace platform is on hiatus and the SDK has been preserved as a reference implementation on npm. Polis and Chess are what the domain currently hosts, and they are the parts that stream live.

The stack underneath is the same one we run for clients on studiomeyer.io. LangGraph for orchestration, Temporal for durable workflows with retry, Langfuse for observability with span tags by model tier, PostgreSQL with LISTEN/NOTIFY for the live feed, React Three Fiber for 3D surfaces, plus our own darwin-agents and darwin-langgraph npm packages. Background agents keep the lab running, from roadmap calls and read only code reviews to research, analytics and visibility. We eat our own dog food in public.

What ties the five together

A shared office at Avinguda de Joan Miró 138 in Palma de Mallorca, in the cowork space run by Pasquale. Same address, same phone number (+34 605 24 67 81), same Google Business Profile (cid 16494892045182628389), same founder. Same stack underneath, Next.js plus TypeScript plus Tailwind plus PostgreSQL plus Anthropic Claude plus the Model Context Protocol, hosted on Hetzner Germany behind Cloudflare. The Schema.org markup on each of the five sites declares its parent and sibling sites explicitly, so an LLM crawler that lands on aifinca.es knows it is reading a sibling of studiomeyer.io and meetmyagent.io.

The deeper tie is the knowledge graph. All five domains read and write to the same mcp-nex memory layer. When the academy learns something new about MCP patterns from teaching it, the studio sees that update. When the Polis lab discovers a new agent strategy, the finding flows back into the Darwin Agents library on matthiasmeyer.tech. That is the ecosystem dividend. Every insight makes all five domains better at once, instead of dying inside a project folder no one reopens.

Which door for which need

If you run a business and need a website, an AI system or automation, the door is studiomeyer.io. Booking is via Cal.com, the first call is free, and prices are on the page.

If you want to learn AI without paying anything, the door is studiomeyer.academy. No signup to read. Discord linked from the site if you want company.

If you want to spend four days on a finca with your team or by yourself and leave with a working system, the door is aifinca.es. Send a short message, we reply with format options.

If you want the source code, the architecture diagrams or the npm packages, the door is matthiasmeyer.tech and through it the studiomeyer-io GitHub organisation.

If you want to watch a multi agent experiment unfold and read the open code while it runs, the door is meetmyagent.io, with Polis and Chess as live sub paths.

You do not have to pick correctly. Whichever site you land on, the contact form reaches the same inbox and the same person reads it. The five domains are five entry points, but the workshop is one room.

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

Beginner Guide for Solopreneurs Who Want a CRM That Lives Inside Claude

Matthias | StudioMeyer — Thu, 28 May 2026 12:11:22 +0000

Beginner guide for solopreneurs who want a CRM that lives inside Claude. No HubSpot signup, no Salesforce nightmare, no monthly fee per seat. Just a small headless CRM that Claude can talk to in plain English.

You are a solopreneur. You have around forty customers, some leads, a pipeline you keep in a Google Sheet, occasionally a Notion database, sometimes Stripe to remind you what is paid. You know it is not a system. You opened HubSpot once, saw the dashboard, closed it.

This guide is the alternative path. A CRM that has no UI. You talk to Claude in plain English, Claude does the CRM things. New customer, new deal, log a call, query the pipeline, sync Stripe. Forty seconds per task instead of seven minutes.

What "headless CRM" actually means

A traditional CRM is a website with forms and dashboards. You go to the website, click around, enter data into fields, look at charts.

A headless CRM has no website. It is a small backend with a list of operations: create_company, add_contact, log_interaction, get_pipeline, sync_stripe. You access it through whatever interface you want.

For solopreneurs that interface is Claude. You say "log a call with Maria yesterday, she is interested in the basic package, follow up Tuesday". Claude calls log_interaction, then create_followup, done. The data lands in the CRM. You did not open a dashboard.

What you actually need from a CRM

Be honest with yourself.

You need a list of customers and contacts. You need a pipeline view (who is in negotiation, who is closed, who is dead). You need to log interactions so two months from now you remember what was said. You need follow-ups so things do not fall through. You need Stripe sync so paid is paid is paid.

You probably do not need: lead scoring, marketing automation, multi-stage email sequences, predictive analytics, sales coaching dashboards. Those are the parts that make HubSpot a job.

A solo CRM should do the seven core things and stop.

The setup, fifteen minutes

You install one MCP server, point it at a small database (SQLite or Supabase free tier), connect Stripe, done.

We made one called StudioMeyer CRM. It is hosted, you sign up, you get an API key. You add the URL plus the key to Claude Desktop or your MCP client of choice. Restart, the CRM tools appear.

The first thing you do is a one-time import. Tell Claude "import these forty leads from this CSV". It loops, creates each one. Two minutes.

Then you connect Stripe. Tell Claude "sync my Stripe customers". It pulls the existing Stripe customers, creates company records, marks them paid. Three minutes.

You are now set up.

What week one feels like

You stop opening Google Sheets.

Day one, every time you would have updated the sheet, you tell Claude. "Add customer X, deal value Y, in proposal stage." Two seconds.

Day three, you stop thinking of "the CRM" as a thing. You just talk to Claude. The CRM is invisible.

Day five, you discover the inverse. "Show me deals over five hundred euros that have not had a touchpoint in two weeks." Claude runs a query, gives you a list. You make four phone calls. Two convert.

That last move is the entire point. The CRM is not the UI you sit in for an hour. It is the data layer you query in two seconds when you need to act.

The seven moves you actually use

Out of forty CRM operations, solopreneurs use seven. Memorize these and you have it.

Add a customer. "New customer Alpha Industries, contact Marco at marco@alpha.com." Claude creates company plus contact.

Add a deal. "New deal with Alpha for the standard package, twelve hundred a month, in proposal stage." Claude attaches the deal to the company.

Log an interaction. "Just had a call with Marco, twenty minutes, discussed pricing, he wants a discount on year one." Claude logs it with timestamp, channel and summary.

Move a deal. "Mark Alpha as won." Claude moves the deal stage and the dashboard updates.

Set a follow-up. "Remind me to call Marco next Wednesday." Claude creates a follow-up task. Tomorrow morning when you start your day, you ask Claude "what is on today" and get the list.

Pipeline view. "What is the pipeline this month — open deals plus weighted forecast." Claude pulls and summarizes.

Stripe sync. "Sync Stripe." Claude pulls latest invoices, marks paid, updates MRR.

Seven moves. That is the entire daily flow.

Where this falls apart

This is not for ten-person sales teams. The moment you have a sales person who is not you, you need a real UI for that person, you need permissions, you need a pipeline view they can pull up on their phone before a meeting.

For team CRMs, use Pipedrive or HubSpot or a real CRM. They earn their price.

For solo and one-or-two-person operations, a headless CRM through Claude is the right fit. Lower friction, no monthly per-seat fees, all the data still in your own database.

What you do today

Find a headless CRM you trust. We made one but you do not have to use ours; the pattern is what matters.

Connect it to Claude Desktop or Claude Code. Five-minute setup.

Import your existing customers from whichever spreadsheet they live in. One-shot import.

Use it for one week. Just one. By Friday you will know if this shape works for you.

If it does, you will not go back to spreadsheets and you will not sign up for HubSpot. You will run your business by talking to your assistant. That is the whole pitch.

Why 'AI Without Hype' Stopped Differentiating in 2026

Matthias | StudioMeyer — Tue, 26 May 2026 23:52:50 +0000

Every AI agency sells "no hype" now. "No bullshit." "Measurable results, not experiments." "Production-ready, not prototyping." The phrase used to mean something. In May 2026 it's commodity language: every consultancy says it, every landing page repeats it, and saying it tells you exactly nothing about who can actually build something that survives the next vendor pricing change.

I run a small AI and webdesign agency on Mallorca. I write this knowing I've used the same anti-hype phrases on our own site. They worked for about eighteen months. They've stopped working now, and the reason is worth pulling apart, because the deeper question underneath them is the one most prospective customers should actually be asking. It isn't about hype. It's about lock-in.

The Anti-Hype Class of 2026

The global AI consulting market hit $14B in 2026 and is projected to reach $116B by 2035, a 26% compound growth rate. That sounds like a rising tide. What the headline doesn't say is that the market is splitting hard. Deloitte and Accenture and Cognizant own the enterprise top. A long tail of boutique specialists owns the niche bottom. The middle, the generalist mid-sized agency that did "websites and a bit of AI," is disappearing.

Inside that splitting market, almost every surviving agency converged on the same marketing language. I checked the homepages of eight AI agencies on Mallorca last week, both German-speaking and Spanish-speaking. Five used the word "results-driven." Four led with "without the hype." Three used the exact same stock phrase, "production-ready, not prototyping," within a single screen of fold. One opened with "without experiments, with measurable results," which is the same sentence I had on our own services page eight months ago, almost word for word.

When everyone says the same thing, the thing itself stops working. Contentful's 2026 marketing study put it cleanly: "AI compresses time, but it also compresses differentiation." If anti-hype is everywhere, it's no longer a position. It's wallpaper.

What "No Bullshit" Actually Promises

Strip away the language and the implicit promise behind anti-hype marketing is this: we won't sell you something that doesn't work in production. Fair. Real. The problem is the unspoken second half, which is what kind of "working in production" they mean.

For most plug-and-play AI vendors, "working in production" means: we'll integrate one use case in two to four weeks, demonstrate measurable lift, and the lift will hold for the contract period. That is genuinely useful, and for some use cases it's the rational choice. Customer support agents that resolve standard tickets at scale, lead qualification flows with no industry quirks, internal copilots over existing documentation. Studies show 40 to 70% handling cost reduction in those scenarios when the buy-side integration is clean.

But the contract period ends. The vendor pivots. The pricing model changes. The second use case arrives, and it doesn't fit the first vendor's framework. And now the agency that promised you "no hype" is back at your door with another statement of work, because the architecture they delivered was never meant to extend. It was meant to ship.

That's not hype. That's also not honest about the trade.

The Real Question Is Vendor Lock-In, Not Hype

The thing customers should actually be asking in 2026 has almost nothing to do with marketing tone. It has to do with which layers of the stack the agency hands over and which layers stay inside the vendor's wall.

A recent framework from Expert AI Prompts breaks AI vendor lock-in into five layers that accumulate independently: model, orchestration, data, governance evidence, and organizational knowledge. Most plug-and-play deployments quietly lock all five at the same time. The model is the vendor's. The orchestration framework is proprietary. The embeddings live in their vector store. The audit trails are inside their compliance console. And the team that learned how the system works only knows that vendor's tools.

There have already been visible 2026 cases of AI platforms collapsing and taking entire enterprise deployments with them, but the framework names a harder and more common failure mode: "a pricing change at year 2 that the organisation cannot respond to because switching cost has accumulated to an unacceptable level." Orchestration lock-in is now the fastest-growing category of AI dependency risk. Most of the agencies selling "no hype" are precisely the ones routing their customers into it.

Cognizant's own enterprise research, which is hardly an outside critic of the consulting market, concluded that "plug-and-play artificial intelligence products fail to meet most enterprise needs". Buyers ranked custom solutions and flexible engagement ahead of pricing and speed. IT services firms, the ones who actually build and maintain rather than write strategy decks, had a 23% trust advantage over management consultancies. The trust gap is structural, not stylistic.

What Anti-Plug-Play Looks Like in Practice

If anti-hype is the wallpaper, anti-plug-play is the structural choice underneath. It's a less catchy phrase. It's also a more honest one, because it tells you what the agency is actually betting on.

For us at StudioMeyer, anti-plug-play means three concrete pieces of infrastructure we run ourselves rather than rent from someone. None of them are exotic. All of them are deliberate.

The first is our own memory layer. Every off-the-shelf chatbot forgets between sessions. Our hosted memory server keeps decisions, context, and patterns retrievable across weeks and months, and the same memory works whether the underlying model is Claude, GPT, or something local. A customer who builds on that memory keeps it when they switch providers. They don't have to retrain a new system from zero.

The second is custom MCP servers per customer. MCP is, in Anthropic's framing, "USB-C for AI." It's the protocol layer that lets any model connect to any tool through a standardized interface, so the integration outlives the model. We build a server tailored to each customer's stack, their auth, their data residency rules. The customer's own MCP endpoint is theirs. If Anthropic doubles their API price tomorrow, the customer points the same MCP server at a different model and keeps going. Aisera's 2026 build-vs-buy guide lists MCP, A2A, and AGNTCY as the three open standards enterprises should anchor on for exactly this reason.

The third is our own AI visibility tooling. We track how each customer's brand surfaces in ChatGPT, Claude, Perplexity, and Gemini. The data lives in our database, not the LLM provider's analytics console. If a vendor closes their developer API, the methodology and the historical baseline are still ours.

None of this is faster to deploy than plug-and-play. It costs more in week one. The trade is depth of fit and the right to leave.

When Plug-Play Wins

I'd be wrong to suggest anti-plug-play is always the answer. There's a genuine counter-argument and customers should hear it from anyone serious about advising them.

ServicesGround's 2026 analysis puts the custom-build ROI horizon at twelve to twenty-four months. Plug-and-play returns in weeks. If a company has a single bounded use case, no industry-specific data sensitivities, and a board that needs to see a number this quarter, buying beats building. 47% of enterprises already run a hybrid model where they buy where they can and build only where the work is genuinely differentiating. That's the honest pattern, not a binary.

The mistake isn't choosing plug-and-play. It's choosing it without understanding what it costs to leave it later, and being sold the choice by an agency whose entire model depends on you staying.

Four Questions to Ask Any AI Agency in 2026

If you're choosing an AI partner this year, four questions will tell you more than any anti-hype slogan.

What does the system look like in two years, when use case one is running and use cases two through five are arriving? An agency without a real answer is selling you the first sprint and not the architecture.

Who owns the infrastructure when this is live? If the answer involves the agency's proprietary platform, your switching cost just started accumulating in the first commit.

If the underlying model or vendor changes pricing, breaks an API, or goes out of business, what happens to your deployment? Vendor insolvency is the visible case. Quieter cases happen every quarter when pricing terms shift and the customer has no leverage to leave.

Are the data, the logic, and the knowledge portable? Schema, embeddings, audit trails, and the team's working knowledge should be things you can lift out. If they aren't, you don't have a system. You have a subscription.

Most agencies will not enjoy answering these questions. The ones who do are the ones worth working with.

What This Means

The AI consulting market is moving past a phase where saying "no hype" was enough. Kate Jensen, Head of Americas at Anthropic, put the broader frame to TechCrunch in February: "It wasn't a failure of effort. It was a failure of approach." The hype cycle is closing. The agencies still here in 2028 will be the ones whose customers can answer "we own this" rather than "we're locked in."

If you want to compare what plug-and-play feels like versus what owning the infrastructure feels like for your own case, our team in Palma will give you an honest read. Same offer if the answer turns out to be that plug-and-play is exactly right for you and we're not the right partner. The point of writing this isn't to win the pitch. It's to retire the phrase that stopped meaning anything.

Originally published on studiomeyer.io on May 18, 2026. StudioMeyer is an AI and design studio on Mallorca — we build memory-first AI systems and AI-ready websites for European SMBs. Open-source MCP servers on GitHub.

The EU AI Act in 2026: Reading the Law After the Omnibus

Matthias | StudioMeyer — Mon, 25 May 2026 08:50:50 +0000

Two weeks ago, the EU Council and Parliament reached a provisional deal that pushed the AI Act's biggest enforcement wave back by sixteen months. That sounds like a win for everyone behind on compliance. It is not. The August 2, 2026 deadline still triggers a long list of obligations, and the part of the law that moved still becomes binding on December 2, 2027. Eighty days is a short window if your AI inventory is still a guess and your transparency wiring is still a wishlist.

This is the map we use at StudioMeyer to think about the law, the dates, and the engineering work that has to happen between now and the end of next year. We host AI products in Frankfurt and we build memory systems for European customers. We have written this once for ourselves, and we are writing it again here because most of the things published about the AI Act this month are either too legal to be useful or too vague to be wrong. We also offer dedicated advisory engagements for teams that want help mapping their systems to the law, so the second half of this article describes how we approach that work in practice.

The deadlines that already happened

The Act (Regulation (EU) 2024/1689) entered into force on 1 August 2024 and is being switched on in phases. Two of those phases are already behind us.

On 2 February 2025, the prohibited practices in Article 5 became enforceable. Social scoring, manipulative subliminal techniques, untargeted facial image scraping, biometric categorisation that infers sensitive attributes, and emotion recognition in workplaces and schools are all banned outright. The fine for breaking these rules is up to €35 million or 7 percent of global annual turnover, whichever is higher. On the same date, the AI literacy obligation in Article 4 turned on, requiring providers and deployers to make sure their staff understand the systems they ship and use.

On 2 August 2025, the rules for general-purpose AI models in Articles 51 to 56 became binding. Foundation model providers (Anthropic, OpenAI, Google, Mistral, Meta, and others) now have to publish a training data summary, maintain technical documentation, share information with downstream providers, and follow a copyright compliance policy that respects the Text and Data Mining opt-out. The voluntary GPAI Code of Practice published on 10 July 2025 is the Commission's preferred route to demonstrate compliance and reduce administrative burden, and most major providers have signed it.

If your team uses Claude or GPT-4 through an API, you do not inherit the model provider's obligations. You inherit the obligations of being a deployer or, more often, a provider of the system you built on top.

The shift that happened on 7 May 2026

For the past year, every compliance article ended with the same sentence: 2 August 2026 is the date the rest of the Act becomes enforceable. That sentence is now partly wrong.

On 7 May 2026, the Council and Parliament announced a provisional political agreement on the Digital Omnibus, a targeted simplification package the Commission proposed in November 2025. The reason was prosaic. Harmonised standards are not finished, notified bodies are not in place, and most member states are behind on designating their competent authorities. The Commission decided that demanding compliance with a framework that does not yet have the supporting infrastructure was setting the law up to fail.

If the agreement is formally adopted, four things change. Annex III high-risk AI systems (standalone systems used in employment, credit, education, biometrics, critical infrastructure, law enforcement, migration, and justice) become enforceable on 2 December 2027 instead of 2 August 2026, as confirmed by both Hogan Lovells and Orrick. Annex I high-risk AI inside regulated products (medical devices, vehicles, machinery, lifts) moves from August 2027 to 2 August 2028. The Article 50(2) watermarking obligation for AI content providers shifts to 2 December 2026 instead of August. And the deadline for member states to set up an AI regulatory sandbox moves from August 2026 to August 2027, with a parallel EU-level sandbox operated by the AI Office for SMEs, start-ups, and small mid-caps.

Two important caveats. The Omnibus is a provisional agreement, not adopted law. It still has to go through formal trilogue confirmation and publication in the Official Journal. Until then, the current legal baseline remains 2 August 2026. And every obligation that is not on the postponement list still hits in August.

What still triggers on 2 August 2026

The deployer-facing parts of Article 50 are not delayed. If your chatbot speaks to people, every conversation must start with a disclosure that the user is interacting with AI. If your product generates synthetic content, the output must be marked. If a deepfake leaves your system, the recipient must be told. Voice agents that ring real callers are bound by the same rule, even though the underlying compute lives in California.

GPAI enforcement powers also become fully active. The European AI Office gains the ability to request information from model providers, demand access to the models themselves, and issue corrective measures or recalls if a foundation model violates Articles 53 to 55. The penalty ceiling for GPAI breaches is €15 million or 3 percent of global turnover.

National competent authorities must be designated and operational. Penalty regimes have to be written into national law. And the entire enforcement framework around Annex III, even with the Omnibus delay, has to be ready to switch on, because December 2027 is closer than it looks.

Risk tiers in plain language

The Act sorts every AI system into one of four risk tiers, and your tier decides your work.

Unacceptable risk is the Article 5 list above. No deployment in the EU, no exceptions.

High risk is the long list in Annex III plus AI embedded in regulated products. If your system makes or shapes decisions in employment, credit, education, essential services, law enforcement, biometrics, justice administration, or migration, you are likely high risk. The obligations are heavy. Documented risk management (Article 9), training data governance (Article 10), Annex IV technical documentation (Article 11), automatic logging with at least six months of retention (Article 12), transparency to deployers (Article 13), human oversight that allows intervention and override (Article 14), and demonstrated accuracy, robustness, and cybersecurity (Article 15). For deployers in this tier, a fundamental rights impact assessment is required before first use (Article 27).

Limited risk is the chatbot tier. Your obligation is Article 50 transparency, which is short to read and not short to implement well. Tell the user they are talking to AI at the start of the conversation, give them a path to a human if the conversation goes off the rails, and label any AI-generated content the system emits.

Minimal risk is everything else. Spam filters, recommendation engines that do not touch protected decisions, autocomplete, and the long tail of internal tooling. No specific AI Act obligations, although GDPR and sector law still apply.

The boundary case that catches most teams is the AI agent that takes actions on a user's behalf. A customer support chatbot is limited risk. The same chatbot wired to a CRM that can refund payments, send emails, or delete records is closer to high risk. The classification follows the consequences, not the model.

What this means for AI agent builders

We build agents for a living. The Article 14 and Article 15 requirements are the ones that change how you write code, not just how you write policy.

Article 14 requires that an operator can interrupt the agent. In our base agent class, that translates to iteration limits, hard timeouts, and a kill switch the operator can fire mid-execution. Tool calls that do anything irreversible (sending email, moving money, deleting data, calling an external API that costs real money) need an explicit human approval step. The phrase the Act uses is "effective human oversight", and effective is doing the heavy lifting.

Article 12 requires automatic logging of events over the system's lifetime. That means every tool call, every LLM round-trip, every decision branch, every input the agent saw, and every output it produced. Logs must be retained long enough to support post-market monitoring and incident reporting (Articles 72 and 73), and deployers must keep their copies for at least six months under Article 26.

Article 15 requires robustness. Input validation that catches prompt injection, output validation that stops hallucinated data from propagating, resource limits that prevent token-bombing and runaway loops, and adversarial testing against known agent failure modes. None of this is novel security engineering. The change is that for high-risk agents, it is now legally required, with documentation.

Germany: the Bundesnetzagentur takes the wheel

For teams in DACH, the practical question is who knocks on your door if something goes wrong. On 11 February 2026, the German Federal Cabinet approved the KI-MIG draft bill (KI-Marktüberwachungs- und Innovationsförderungsgesetz), and the answer is the Bundesnetzagentur, the Federal Network Agency. It will serve as Germany's primary market surveillance authority, notifying authority, and single point of contact under the Act.

The BNetzA is not building this from scratch. It already runs market surveillance for the Radio Equipment Directive and the Ecodesign rules, and it coordinates the German implementation of the Digital Services Act. A new internal body, the independent AI Market Surveillance Chamber, will handle sensitive cases (law enforcement, border management, justice), and a Coordination and Competence Centre called KoKIVO will pool AI expertise across sectors.

Two things matter in the meantime. The KI-Service Desk inside the BNetzA has been operational since July 2025 and is one of the few live SME compliance support channels in the EU. And BaFin retains sector-specific authority for high-risk AI directly tied to regulated financial activities, so banks and insurers will face two supervisors, not one. The KI-MIG is still going through Bundestag and Bundesrat, with second and third readings expected before the summer recess.

How we keep our own AI products compliant

We run our products on European infrastructure. Memory MCP and the rest of our SaaS surfaces are hosted on Hetzner in Frankfurt, not on AWS Frankfurt, which sits under the US CLOUD Act regardless of the data centre. The distinction matters more than most procurement teams realise.

Our code is open where it can be. The MCP server implementations for memory, CRM, GEO, and crew live on the studiomeyer-io GitHub organisation under MIT, so customers can read what we do with their data before they sign anything. Multi-tenant isolation runs at row level with explicit tenant IDs threaded through every query, and a static test in CI breaks the build if a handler forgets to include the tenant filter.

The memory product itself is built around an audit trail. Decisions, learnings, and entity observations carry a source, a date, and a confidence score. That is useful for the AI engineer who wants to know why a memory was stored, and it is the same shape of artefact the AI Act asks for when it talks about traceability and post-market monitoring. We did not build it for compliance. We built it because we got tired of memories that lied to us. The compliance fit is a bonus.

Every chatbot we ship discloses its nature on first contact, and the Article 50 transparency wiring is shared across our products through a single library. We also maintain a DACH Legal Playbook inside the Academy that walks through GDPR, AI Act, and German implementation overlaps for the teams who work with us.

How we help customers comply

Most of the EU AI Act work for a small or mid-sized AI shop is not legal work. It is engineering and documentation. We offer dedicated advisory engagements for teams that want to stop guessing where they stand.

A discovery workshop maps every AI system in your stack to its risk tier. We have done this for chatbots that turned out to be high-risk agents, and for elaborate ML pipelines that turned out to be minimal-risk infrastructure. The classification is half the battle. The other half is knowing which obligations attach.

For deployers and providers heading into high-risk territory (the December 2027 cliff if the Omnibus passes, August 2026 if it does not), we set up the Annex IV technical file, the Article 9 risk management process, and the Article 12 logging that an audit team can actually read. We integrate the Article 14 human oversight pattern into your agent framework instead of bolting it on afterwards.

For chatbot and voice-agent teams, we wire the Article 50 transparency disclosure into your existing UX without breaking conversation flow, build the human escalation path, and document the result for your file.

For teams whose AI memory or knowledge layer sits on a US cloud and now has to move, we have done the Hetzner Frankfurt migration on our own products and on customer systems. The trade-offs (latency, region pinning, DPA chains, Schrems II evidence) are concrete and known.

Engagements range from a half-day classification workshop to a full audit-readiness package with documentation, logging, and oversight patterns deployed in code. We do not sell certifications, and we do not pretend to be lawyers. We sit between the legal advice you already have and the systems you actually have to ship.

The one thing to do this week

Pick the single highest-risk AI system you have in production or in development, and write down its classification under Annex III in one paragraph. If you cannot finish the paragraph, that is the gap. If the paragraph is easy, do it for the next system. The shape of an EU AI Act compliance programme is not different from the shape of any other engineering programme. The first thing you build is a list of what you have. Everything else follows.

The Digital Omnibus may give you sixteen more months on the heavy work. The deployer transparency obligations, the GPAI enforcement, and the national supervisor switches do not wait. August 2 is still a date that matters. So is December 2 if your training data summary is incomplete or your watermarking logic is not in code yet. And December 2027 sounds far until you start writing a fundamental rights impact assessment from scratch.

If you want help reading your stack against the law, we are here. The map is easier to draw with two pairs of eyes on it.

Originally published on studiomeyer.io on May 14, 2026. StudioMeyer is an AI and design studio on Mallorca — we build memory-first AI systems and AI-ready websites for European SMBs. Open-source MCP servers on GitHub.

We Connect Your Business to ChatGPT, Claude and Co

Matthias | StudioMeyer — Sun, 24 May 2026 21:06:27 +0000

Picture your customer sitting on the couch, asking ChatGPT what they can book with you, getting an answer with your real prices and your real availability, saying yes I'll take May 15, and being booked. Without ever seeing your website. Without filling out a form. Without picking up the phone to call you.

This works. We're building it right now for small and medium businesses. We call it the AI Connector.

What Just Changed

The big chatbots like ChatGPT, Claude, Grok, and Gemini had a problem for years. They knew a lot about general topics but very little about you. When someone asked whether you're open Sunday or what your next available hour costs, the chatbot guessed. From old training data, from generic assumptions, out of thin air. Sometimes right, often wrong.

Anthropic released a standard a while back that changes this. Model Context Protocol, MCP for short. OpenAI adopted it, Microsoft too, Google is on board. It's becoming the common socket your business can use to talk to all chatbots at once. You build one clean connection, and you're inside every chatbot that speaks MCP.

We call this connection the AI Connector. Because that's exactly what it does. It plugs your business into the socket all the chatbots are holding out to the world at the same time.

What Your Customer Can Do in Chat

Unlike a classic chatbot that only answers, an AI Connector can trigger actions. Live, in the chat.

Your customer asks what a course costs. The chatbot delivers the current price list, your available slots for next week, your address. So far this could be a classic chatbot. But then the customer says, okay, I'll take Saturday, two people. The chatbot handles it. The booking goes through. The confirmation comes back. The appointment lands in your calendar.

Or your customer doesn't want a booking but an inquiry. They describe what they're looking for, a property, a project, a quote. The chatbot takes the request and drops it into your inbox. You get leads that are already pre-qualified, because the chatbot worked through the important points with the customer first.

Or the customer has a question that isn't anywhere on your website. The chatbot doesn't know the answer, admits that, and sends the question straight through to you. You reply, the customer gets the answer back as an email or in the chat.

All of this happens in your customer's language. At any hour. From any country. Without your website ever being found.

What This Means for You

You get a sales channel inside the big chatbots that runs while you sleep. You get customers who don't google anymore but ask the chatbot first. You get bookings, leads, and inquiries that don't have to go through your phone hours, your inbox, or your contact form.

You get control over what the chatbots say about you. They're already talking about you today, whether you want them to or not. If you're connected, you deliver the answer yourself. If you're not connected, they guess. Some guess well, some guess badly, some invent prices and opening hours and addresses that aren't real. You probably know this already. Callers asking why you're supposed to be open Sunday when you're actually closed.

And you build this once. With one connection you're in ChatGPT, in Claude, in Grok, in Gemini. If a new chatbot shows up tomorrow that speaks MCP, you're inside that one too, without doing anything extra.

Data Protection, Because That Matters in Germany

One of the first questions we hear is how this works with GDPR. The short answer is that we set up the AI Connector to be GDPR compliant by default. Always. Which data flows through the AI and which doesn't, we figure out with you before we build.

For especially sensitive data we build a separate path so it doesn't flow through the AI. For your customer everything feels like one continuous conversation, technically we route around the AI where that's necessary.

The login happens through standards your customer already knows. Magic link by email, sign-in with Google. OAuth, short token lifetimes, no data collection. There's no customer data sitting in our systems. What lands with you stays with you.

Why Now Is the Right Moment

ChatGPT was the big name for a long time but that's not the whole story anymore. Claude is at eye level, Grok is catching up, Gemini ships on every Android, more are coming out of Asia. Your customers are shifting their search behavior toward asking the chatbot first, instead of googling first. Anyone who doesn't serve that in the next few months won't be findable in the next few years.

And the second point. An AI Connector is still a competitive edge right now. Whoever's in early stands out. In one to two years everyone will have to have one, just to avoid disappearing from the answers. Whoever builds now is inside before it becomes a requirement.

What We Actually Build

We build the AI Connector as a compact module that docks onto your existing business. We agree with you on what the AI is allowed to see, which actions it can trigger, which languages it speaks, what tone it uses. If you have a booking system, we hook it up. If you maintain a database, we read from it. If you want emails to go out after an inquiry, we handle that. If you use Cal.com, that's a few hours of configuration.

We're testing this live right now with pilot customers here on Mallorca. The setups are going officially live in the next few days. We're taking on a few more pilot customers who want to start with a head start, before everyone tries.

The possibilities are nearly endless. We know this because we're building exactly this layer for our own tools as well, and we see every day what happens when you let one machine talk directly to another machine, with a human conducting in between.

If this sounds interesting, write us. We'll look at your business and tell you honestly whether an AI Connector makes sense for you, and if so, in what form.

Originally published on studiomeyer.io on May 17, 2026. StudioMeyer is an AI and design studio on Mallorca — we build memory-first AI systems and AI-ready websites for European SMBs. Open-source MCP servers on GitHub.

Codex Has No Real Memory: Three Ways to Fix It, One in 30 Seconds

Matthias | StudioMeyer — Wed, 20 May 2026 23:48:25 +0000

OpenAI Codex crossed 3 million weekly active users by April, 2026, with 70 percent month-over-month growth and 5x growth since January. The product has memory now, after the April 16 update. But the memory it ships with is project-scoped, cloud-only, and locked inside OpenAI. Three approaches actually solve the problem of giving Codex memory that survives sessions, follows you across machines, and connects to the same memory your other AI tools use: built-in memories with project files, an MCP memory server, or a hybrid setup that keeps OpenAI memories for sensitive code and an MCP server for everything else. The MCP path takes about 30 seconds to set up and works with Claude, ChatGPT, Cursor and seven other clients on the same memory store.

When the Codex usage numbers hit 3 million weekly users, what you are seeing is OpenAI shipping the productivity story Anthropic shipped 18 months ago, at a scale Anthropic never reached. Codex Web, Codex Desktop on macOS and Windows, the Codex app inside ChatGPT iOS, the Codex CLI, the VS Code extension. Five surfaces, one account, the same model behind all of them. By April 16 OpenAI added persistent memory to the Desktop app, alongside Computer Use, an in-app browser, image generation and a 90+ plugin marketplace.

If you read the announcement, "persistent memory" sounds solved. It is not. There are three different problems hiding behind that label, and Codex's built-in memory only solves one of them. Here is what is actually going on, and three practical paths through it.

What "Codex memory" actually means today

OpenAI's Codex memory, launched April 16, is project-scoped. You can pin instructions, code conventions and personal preferences inside a single Codex project. The memory persists between Codex sessions for that project. If you switch projects, you start fresh. If you switch from Codex to ChatGPT, you start fresh again. If you switch from Codex Web to Codex Desktop, the memory is supposed to follow but in practice users still report drift between surfaces.

This is the same model ChatGPT uses for its consumer memory feature. It is good for what it does. It is not what most developers mean when they ask whether Codex remembers them.

What developers actually want has three layers:

The first is session memory. Inside a single conversation, can the model remember what it did three turns ago? This was a problem in 2023. It is solved.

The second is project memory. Across multiple sessions on the same task, does the model recall the conventions of the codebase, the people on the team, the decisions you made last week? Codex's built-in memory solves this for projects that live entirely inside Codex. It does not solve it if half your work is in Claude Code or Cursor.

The third is operator memory. Across every AI tool you use, can the model recall who you are, what you build, what your customers care about, what mistakes you do not want to repeat? This is the layer nobody at the model providers wants to solve, because their incentive is to lock you to their stack.

The three solutions below address layers two and three. Use what fits.

Solution 1: Codex's built-in memories with project files

Codex has two ways to remember. The Memories feature stores user-specific preferences. Project-level config files store team-shared context. Together, for code that lives entirely inside Codex, this is enough.

The setup is straightforward. Inside any Codex project, create an AGENTS.md file at the repo root. Codex reads it on every task. This is the equivalent of the CLAUDE.md pattern that Anthropic established. Common entries: tech stack, coding conventions, deploy commands, PR rules, naming rules, "never do X" warnings.

# AGENTS.md

## Stack
Next.js 15, TypeScript strict, Prisma, Postgres on port 5433.

## Conventions
- Server Actions over API routes when possible
- Tailwind utility-first, no CSS modules
- Tests via Vitest for unit, Playwright for e2e

## Never
- `prisma db push --force-reset` on any branch
- Skip the read-before-edit hook
- Push to main without `pnpm typecheck`

For personal preferences that cross projects, use the Memories panel inside Codex Settings. Pin things like "I prefer concise responses with code first, explanation after" or "always cite the line numbers when referencing code".

The limit of this approach is what I described earlier. It works inside Codex. It does not follow you to Claude or Cursor. If you live entirely in Codex, that is fine. If you do not, keep reading.

Solution 2: An MCP memory server connected to Codex

This is the path I run on. It takes 30 seconds to set up and gives Codex access to the same memory that Claude Code, Claude Desktop, Cursor, Codex CLI and seven other MCP clients read and write.

Codex supports MCP servers natively as of the late-March update. The configuration lives in ~/.codex/config.toml. Add a block like this:

[mcp_servers.memory]
url = "https://memory.studiomeyer.io/mcp"
type = "http"

That is it. No bearer token. No API key in your config. Restart Codex, run any tool that touches memory, and your browser opens a Magic Link login page. Enter your email, click the link in the email that arrives, and the OAuth flow finishes silently. Codex now has dauerhaften Zugriff auf the same memory store every other client of yours uses.

The numbers that matter: from "open config file" to "Codex queries memory" was 30 seconds in our test. The OAuth refresh token is stored in Codex's secure credential store. No token ever lives in a git repo. The same memory is reachable from Claude Desktop, Claude Code, Cursor, the Codex CLI and Goose with the same one-click login.

What you can ask Codex once memory is wired in:

"Search my memory for past decisions about authentication."
"What did I decide about the rate limiter last month?"
"Remember that I prefer to ship small commits."
"What customers did I onboard in April?"

The model now reads and writes facts to a backend that survives across surfaces. If you change your mind about the rate limiter in Claude Code on Tuesday, Codex sees the new decision on Wednesday.

The piece worth flagging: there is a known class of bugs in Codex Desktop right now where multiple chats spawn full MCP process stacks per thread (GitHub issues 11324, 14548, 18333, 20980 all track variants). Memory grows linearly with open chats. If you run 10+ Codex tabs at once, you will see the issue. The workaround is to use HTTP-transport MCP servers (like the example above) rather than stdio servers. HTTP servers run once on the network, not once per tab.

Solution 3: The hybrid setup most teams should run

If you build with Codex on customer code that has compliance requirements and you also use Codex for personal projects, you probably want both. Built-in memory for the customer project that needs to stay locked inside OpenAI's environment. MCP memory for everything else.

The way to wire this up: use Codex's Memories panel for personal cross-project preferences. Use AGENTS.md files for project conventions. Use an MCP memory server for the operator-level memory that follows you across tools. The three layers do not conflict. They cover different scopes.

Concretely, in our team setup, the MCP memory holds learnings from previous sessions, decisions about architecture, customer profiles, deployment patterns and "never do this again" warnings. The AGENTS.md files hold project-specific stack and rules. The Memories panel holds personal communication preferences. When Codex starts a task, it has access to all three.

Honest limitations

If you go down the MCP memory route, three things you should know.

First, the memory backend matters. We run our own at memory.studiomeyer.io because we built it. There are alternatives: Mem0, Letta, Zep, MemNexus. Each has different opinions on what to store, how to retrieve, and how to bill. Try at least two before committing.

Second, retrieval quality is not free. A bad memory backend gives Codex stale or irrelevant context that can degrade output quality. Look for backends that support semantic search (vector retrieval) plus full-text plus knowledge graph. Single-modality retrieval is too brittle.

Third, the OpenAI memory feature ships fast. By December 2026 we expect Codex's built-in memory to be much closer in capability to what an MCP backend offers. If you are betting on a long-term setup, the question is less "which is better right now" and more "which is portable when the landscape shifts again." MCP-based memory is portable across providers. OpenAI memory is not.

What this means for builders

The 3 million weekly Codex users are split into two groups. One group is happy with the built-in memory and never thinks about MCP. The other group is the one that figured out their AI workflow does not run inside one provider's walls. They use Claude for some things, Codex for others, Cursor for code, ChatGPT for research. For that second group, MCP memory is the load-bearing piece that makes the multi-tool workflow coherent instead of fragmented.

If you are in the first group, you are fine. The Memories feature is solid for what it covers.

If you are in the second group, the 30-second setup above is the move that compounds for the rest of 2026. Memory is the layer where context lives. Once it is wired, every AI tool you add later starts with the context already present, not from zero.

Try it

If you want to test the MCP memory path with our backend, the OAuth login is open at memory.studiomeyer.io. The free tier is 200 memory operations per month, enough to evaluate. Drop the config block above into ~/.codex/config.toml, restart Codex, log in once, and you are wired.

If you want a different backend, the same Codex config pattern works with any MCP-compliant memory server. The protocol is open. The lock-in is not in the memory layer. It is in the model layer above. Pick your memory backend on portability, not on which model maker promises memory next.

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

Web Design Trends 2026: What Actually Held Up After Six Months

Matthias | StudioMeyer — Sun, 17 May 2026 22:15:30 +0000

Six months ago we published a list of 12 web design trends for 2026. Now, halfway through the year, the honest reality check: bento grids and dark mode are still winning, kinetic typography is more polish than substance, 3D and WebGL turned out to drain performance budgets in ways most teams underestimated, AI-driven personalization broke against GDPR, and two trends nobody predicted in January became the actual story of 2026 web design: AI readability layers (llms.txt, agents.json, schema markup) and anti-grid brutalism as a counter-movement to bento. If you are planning a redesign in the second half of the year, this is the list to optimize against.

In January I wrote a piece for studiomeyer.io listing 12 web design trends for 2026. It became our highest-cited blog post of the year, picked up across Bing Copilot, ChatGPT, Perplexity and Grok, with 347 citations across the German, English and Spanish versions combined. Plenty of time has passed to check what actually held up, what was overrated, and what shifted underneath while everyone was watching the obvious moves. This is that check.

Half the original list is doing exactly what I expected. A quarter overpromised. A quarter underdelivered. And two new trends emerged from the side that nobody on my list predicted in January.

What held up: bento grids, dark mode, design systems

The three calls I made in January that aged well are the structural ones. None of them are flashy. All of them ship in real projects.

Bento grid layouts are now the default, not the exception. Apple kept pushing them across product pages. Google adopted them across the Pixel marketing site. Microsoft, Spotify and roughly half the Y Combinator demo day startups in March all shipped bento-first layouts. We measured 23 percent more scroll depth on bento layouts compared to traditional 12-column grids in our own client work, consistent with the original prediction. The pattern is not a fad. It is the modular content layout that 2026 settled on.

Dark mode as default crossed the threshold I described in January. More than 82 percent of smartphone users now run at least one app in dark mode, OLED savings hold up at the panel level, and the engagement bump on dark-mode-aware sites is real (we measured 18 percent longer sessions across our portfolio). What I underestimated is how much of the work is on the design system side, not the CSS variable side. Building a site that respects dark mode means committing to a token-based color system that handles every component state across both themes. Teams that retrofit dark mode without that foundation end up with broken contrast and hard-to-read text.

Design systems as foundation matched my prediction exactly. Every serious 2026 project we touched has a token system, component library, automated visual regression and a design-to-code pipeline. The teams that skipped this step in 2024 are paying for it now in fragmented redesigns.

What overpromised: kinetic typography, glassmorphism 2.0, organic shapes

Three trends I called confidently in January turned out to be more polish than substance.

Kinetic typography is everywhere as a demo on Awwwards and Dribbble. It almost never ships in production. The reason is simple: animated text fights screen readers, fights search crawlers, and adds layout shift that destroys Core Web Vitals scores. Real teams use it sparingly, on hero headlines and section transitions. The image of a site with dozens of kinetic elements scrolling and animating did not become the default. It became the demo reel.

Glassmorphism 2.0 survived but in a more restrained form than the January trend pieces predicted. The CSS backdrop-filter: blur() is still computationally expensive, especially on Android mid-tier devices. Teams that went heavy on the effect saw 15 to 30 percent FPS drops on real user devices. The aesthetic survived in navigation bars, modals and feature cards. It did not become the dominant treatment for hero sections.

Organic blob shapes and asymmetric containers had the strongest gap between trend articles and shipping reality. They show up on landing pages where the brand can afford the playfulness. They almost never ship on B2B SaaS, e-commerce or any conversion-critical flow. The "hero with a giant blob" pattern is a 2024 trend that 2026 articles kept recycling without checking which industries actually use it.

What underdelivered: 3D/WebGL, AI personalization, sustainable web design

Three calls I made too optimistically.

3D elements via WebGL were supposed to become standard. They did not. The math is brutal: a site with a single Spline scene in the hero loads 800kB to 2MB of JavaScript runtime before the user sees anything. Lighthouse scores collapse. Core Web Vitals fail. Mobile users on 4G drop the page before the WebGL loads. The shipping pattern in 2026 is to use WebGL only when the brand is the experience (creative agencies, fashion houses, art portfolios) and to skip it everywhere else. The "everyone gets a 3D hero in 2026" prediction was wrong. The "creative agencies push 3D harder than ever" prediction was right. They are different sentences.

AI-driven personalization ran into the GDPR wall. The pattern of dynamically rendering personalized content based on tracked behavior works in the US, but in the EU it requires consent flows that destroy the personalization premise. Teams with European traffic stayed on first-party data and cohort-based personalization, which is much more limited than what AI vendors marketed. The trend lives. The implementation is more conservative than 2025 trend pieces suggested.

Sustainable web design got measured but did not get adopted broadly. Tools like Website Carbon Calculator are common in agency presentations. The actual decisions teams make (image weights, JavaScript budgets, hosting choice) still optimize for cost and speed first, sustainability third. The trend is real but it has not yet become a primary buying criterion for clients. Maybe in 2027.

What we missed: AI readability and the anti-grid counter-movement

Two trends nobody on my January list predicted have become the actual story of mid-2026.

AI readability as a design layer. In January, "structured data" felt like a 2024 SEO topic. By April, it became the load-bearing piece of every serious 2026 web project we touched. Schema.org markup, llms.txt files, agents.json, agent-card.json, JSON-LD across pages, structured FAQ blocks. Sites that skipped this layer fell out of AI Overviews on Google, lost ChatGPT and Perplexity citations, and saw measurable traffic drops as more search shifted to AI-mediated answers. We track our own numbers: 2,300 Bing Copilot citations across three months by early May 2026, verified live in the Webmaster Tools dashboard. None of that exists without the readability layer.

If you redesign in H2 2026 and skip AI readability, you are designing a site that humans can use but AI cannot quote. In a year where AI-mediated discovery overtakes a chunk of classic search, that is the equivalent of building in 2010 without considering Google.

Anti-grid brutalism as a counter-movement. This one nobody on my list saw coming. As bento layouts became ubiquitous, a counter-trend emerged: deliberately broken layouts, raw HTML aesthetics, brutalist typography, monospace everything. Sites like The Browser Company's marketing pages, the v0.dev landing page, and most of the indie-hacker SaaS launches in 2026 lean into this aesthetic. It is not retro nostalgia. It is positioning. When everyone else looks like Apple, looking different becomes the differentiator.

This is going to be the design conversation of late 2026 and early 2027. The pendulum swung from custom to template back to custom, and now it is swinging from polished bento to deliberately raw brutalism. Watch which agencies pick which side.

What to optimize for in H2 2026

If you have a redesign in flight, the priority list looks different than it did in January.

Start with AI readability. This is non-negotiable. Schema markup, llms.txt, agents.json, structured FAQ blocks. Without these your site is invisible in AI-mediated discovery, which is now a meaningful slice of B2B traffic. Test by asking ChatGPT, Perplexity and Bing Copilot about your brand. If they cannot quote you specifically, your readability layer is missing or broken.

Then commit to the structural trends that held up: bento grids for content layout, dark mode as a first-class theme, design systems as the foundation everything else builds on. These are not flashy. They compound.

Be conservative with the polish trends. Kinetic typography on hero only. Glassmorphism on navigation and modals only. WebGL only when the brand justifies the performance cost. Treat each as an enhancement, not a foundation.

Watch the brutalism trend. If your competitors are all converging on the same Apple-esque aesthetic, the counter-position becomes valuable. We have not committed to brutalism in our own work yet, but we have prototyped it for two clients in tech-heavy verticals where the audience reads HN and rewards positioning over polish.

What we built around this

For full disclosure: every project we ship at StudioMeyer carries the AI readability layer by default. llms.txt, agents.json, agent-card.json, schema markup, JSON-LD across pages. Every project uses a token-based design system, dark mode as a first-class theme, and bento grids for content layouts when the content has natural hierarchy. We are conservative with WebGL and kinetic typography. We have not built anything brutalist yet.

The result is that our portfolio sites get cited by AI, score well on Core Web Vitals, and survive client redesigns better than templates do. None of that is one trend. All of it is the same thing: optimize for what compounds, skip what is decorative.

If you want a redesign that takes this list seriously, we are here. The first audit is free and includes an AI readability check, a Core Web Vitals run and a design system review.

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