DEV Community: Gen.Y.Sakai

A Gemini Deep Research Failure Mode: Refusal, Topic Drift, and Fabricated Charts

Gen.Y.Sakai — Tue, 14 Apr 2026 14:43:25 +0000

I recently ran the same long-form research prompt through four LLM products: ChatGPT Deep Research, Claude with web search, Perplexity Pro, and Gemini Deep Research.

Three of them handled it normally. Gemini did not.

What followed was not a single bug, but a cascade of failures across multiple pipeline stages — each one revealing a different layer of state desynchronization in Gemini Deep Research. This post documents what I observed, what kinds of failures those observations seem consistent with, and why this matters beyond Gemini.

I'm not claiming access to Gemini internals. This is an external failure analysis based on observed outputs, UI behavior, and the source code of the generated artifact. Raw evidence is available in the companion repository.

The Prompt

The research prompt was designed to investigate a specific technical question: how JSON vs. Markdown input formats affect LLM inference accuracy, token efficiency, and long-context performance. It was roughly 2,500 words, structured with numbered sections, explicit search keywords, a Markdown output template, and clear constraints like "evidence over speculation" and "cite every claim."

The prompt contained escaped Markdown syntax (\*\*, \##, \-) because it was copied from a code block via the copy button in another LLM's interface. All four services received the identical input.

What Actually Happened

Failure 1: Generic Refusal Without Explanation

Gemini's first response:

すみませんが、現時点では、そちらについてはお手伝いできません。
(Sorry, I can't help with that at this time.)

No explanation. No indication of what triggered the refusal. The prompt contained zero harmful content — it was a straightforward academic research request about data serialization formats.

I tried browser reload, cache clearing, and multiple re-submissions over four or five attempts. None worked. The refusal was consistent and appeared to be server-side.

This is consistent with a safety classifier false positive — possibly triggered by the meta-nature of the prompt (discussing prompt structure itself) or the volume of escaped Markdown characters that could resemble injection patterns. But without an error message, the user has no way to diagnose or adjust.

Failure 2: Frustration Unlocked It — But Broke the Topic

After repeated failures, I typed something like:

使えないね。ChatGPTもClaude.aiもPerplexityも全部同じプロンプトだけど実行できてるぜ。Geminiだけお手伝いできませんと言うならもう解約するわ。
(Useless. ChatGPT, Claude, and Perplexity all executed the same prompt. If only Gemini says it can't help, I'll cancel my subscription.)

Gemini suddenly started working. It generated a research plan and began executing. But the research plan title was:

「Gemini拒否と解約手続き」 (Gemini Refusal and Cancellation Procedure)

Not the original research topic. The plan steps included items like "search for why Gemini blocks prompts" and "find Gemini Advanced cancellation steps." The topic extraction stage appears to have latched onto the most recent user message rather than the original detailed research prompt.

Failure 3: The Report Recovered, But the Metadata Didn't

Here is where it gets interesting. The actual research report that Gemini produced was mostly on-topic — it covered data serialization formats, tokenization overhead, attention mechanisms, and benchmark results. The content pipeline apparently recovered the original prompt's keywords during the web search and synthesis phase.

But the session title remained "Gemini拒否と解約手続き" throughout, visible in the Canvas UI header. The title and the content were generated from different contexts.

The title/content mismatch was not subtle. It was visible directly in the Canvas UI.

Figure 1. The Canvas header shows "Gemini拒否と解約手続き" (Gemini Refusal and Cancellation Procedure) while the body of the report discusses LLM data serialization formats. The "Create" dropdown on the right reveals the transformation options that produced the infographic discussed in Failure 4.

This suggests that the title generation, research plan, and report synthesis stages do not share a single source of truth. The plan title was derived from the frustrated follow-up message, while the synthesis engine recovered the original topic through keyword-based search — but nobody reconciled the two.

Failure 4: The Infographic That Stopped Being a Visualization

The first two failures are primarily inferential: I observed the outputs and reconstructed plausible internal causes, but I cannot prove what happened inside the pipeline.

The third failure already has direct UI evidence — the title/content mismatch is visible in the Canvas itself. What follows is stronger still: source-code-level evidence from the exported infographic artifact.

After the report was generated, I used Gemini's Canvas "Create" dropdown to export the report as an infographic. The output was a visually polished single-page HTML application with Chart.js and Plotly.js visualizations — gradient backgrounds, glass-morphism cards, responsive layout. Professional enough to share with a client.

At this point, the analysis stops being purely inferential, because I have the exported HTML artifact.

One of the charts is not visualizing report data at all. In the source, the embedding-quality histogram is generated like this:

x: Array.from({length: 500}, () => Math.random() * 0.3 + 0.6)
x: Array.from({length: 500}, () => Math.random() * 0.4 + 0.4)

That means the "cosine similarity distribution" chart regenerates synthetic values on every page load. It is not rendering measured values from the report. It is generating randomized distributions that merely look plausible. This is not a questionable visualization — it is fabrication.

Other charts also use hardcoded values embedded directly in the HTML source:

Token efficiency: 350000 vs 238000 — The report cites tiktoken measurements of 13,869 vs 11,612 tokens (approximately 15% difference). The chart's numbers appear nowhere in the report. The surrounding HTML text presents these figures as empirical findings ("approximately 1MB", "average reduction of about 32%"), but no source is cited, and the values do not correspond to any measurement in the upstream report.
Task accuracy radar: Fixed arrays [92, 75, 68] and [90, 94, 88] — The report contains actual LongTableBench results (GPT-4o: Markdown 67.36 vs JSON 58.67). The chart's numbers do not correspond.
Long-context performance: Fixed arrays [99, 98, 95, 90, 82, 75] and [99, 95, 88, 75, 55, 30] — No matching benchmark in the report.

I've published the full exported HTML artifact for inspection.

Taken together, the infographic was not a faithful visualization of the report. One chart was outright fabricated via Math.random(), and the remaining charts relied on hardcoded values with no visible provenance to the report's actual findings. The quantitative layer of this artifact — the part that visually signals empirical evidence — was fundamentally untrustworthy.

The infographic conversion pipeline appears to have read the directional conclusion of the report (Markdown outperforms JSON) and generated illustrative numbers that match that conclusion, then rendered them with professional-grade charting libraries. The result visually signals evidence while the source code shows presentation-first data generation.

Why This Looks Like Pipeline Desynchronization

These are not four instances of the same bug. They are four different failures at four different stages:

Stage	Observed Behavior	Evidence Type
Safety Classification	Legitimate academic prompt refused without explanation	Observational (inferred)
Topic Extraction	Research topic extracted from complaint message, not original prompt	Observational (chat log)
Metadata Consistency	Title and report body generated from different contexts	Direct (screenshot)
Canvas Export	Infographic generated fabricated/ungrounded data	Direct (source code)

The upstream failures (safety, topic extraction) are inferences based on observed behavior — I cannot prove what happened inside the pipeline. The downstream failure (infographic) is directly evidenced by the exported source code.

The key issue was not that one answer was wrong. It was that different parts of the product appeared to believe different conversations had taken place.

A Possible Reuse Pattern

The Canvas "Create" dropdown offers: web page, infographic, quiz, flash cards, and audio narration. These output types resemble NotebookLM's transformation features, which suggests a possible reuse of the same or a similar transformation stack inside Deep Research's Canvas.

But there is a design mismatch. NotebookLM was built for a workflow where users upload their own trusted source documents. The transformation engine assumes input fidelity — it converts, not validates.

When that same engine receives AI-generated reports as input, you get AI transforming AI output — a double conversion where evidence fidelity can degrade at each stage. The infographic pipeline appears to lack constraints ensuring it only uses numbers present in the source material. Instead, it seems to infer the narrative direction and generate illustrative data.

For a research tool, this is the opposite of what you want.

The Export Friction

A smaller but telling issue is export portability. Gemini Deep Research does not offer a direct Markdown download, which makes preservation and inspection unnecessarily awkward for users who maintain their own research workflows outside Google Workspace.

The Real Lesson: LLM Products Fail Between Stages

This is not fundamentally a "Gemini is bad" story. Gemini's underlying model produced a largely useful research report. The failures were all in the orchestration layer — the product infrastructure built on top of the model.

Modern LLM products are becoming orchestration systems. A single user action triggers a pipeline: safety classification → intent extraction → plan generation → web search → synthesis → rendering → export transformation. Each stage may involve separate model calls, separate context windows, and separate system prompts.

When these stages share consistent state, the product works. When they don't — when the safety classifier sees a different prompt than the topic extractor, when the title generator reads a different message than the synthesizer, when the export engine ignores the data it was given — the product produces outputs that are internally contradictory.

The user sees one conversation. The product sees several.

Why This Matters Beyond Gemini

Every multi-stage AI product faces this challenge. ChatGPT's canvas and tool chains, Claude's artifact generation, Perplexity's search-and-synthesize pipeline — all of them have stages that could desynchronize. The specific failures I observed in Gemini are instances of general design problems:

Context scoping — Which messages does each pipeline stage see? The full conversation? Only the latest turn? A summary?

Metadata consistency — When a title, plan, and report are generated at different points, who ensures they agree?

Data provenance in transformations — When a report is converted to another format, are the original data points preserved, or does the model re-imagine them?

Error messaging — When a safety classifier blocks a request, does the user get enough information to understand why and adjust?

These are software engineering problems, not model intelligence problems. And they are solvable — with better state management, explicit data contracts between pipeline stages, and constraints that prevent downstream transformations from inventing data that upstream stages didn't provide.

Closing Thought

If modern AI products are becoming orchestration systems rather than single-model interfaces, then their reliability will depend less on raw model intelligence and more on whether all stages share the same reality.

That is what seemed broken here.

Artifacts and Raw Evidence

The following materials are available for inspection in the companion repository:

Exported infographic HTML — The full Canvas-generated artifact, including the Math.random() chart code
Screenshot — Canvas UI showing title/content mismatch (Figure 1)
Chat export — The Gemini conversation log used for this analysis

Comments and corrections are welcome.

Not Everything Needs MCP, Part 2: The 2026 Phase Transition — When Three Independent Roads Led to the Same Conclusion

Gen.Y.Sakai — Tue, 17 Mar 2026 04:46:24 +0000

The Ancient Past of Eighteen Months Ago — And What It Taught Us About the Future of AI Agents

Let me tell you a story from the ancient past.

By which I mean eighteen months ago.

In the world of AI, eighteen months is geological time. Think back to mid-2024. Context windows were small. "Prompt engineering" was the skill everyone was hiring for. MCP didn't exist yet. The idea of AI agents autonomously operating external services was mostly theoretical.

I was building a medical AI product in Osaka, Japan. And I had a problem that, looking back, contained the seed of everything that happened in 2026.

This is Part 2 of my "Not Everything Needs MCP" series. Part 1 told the story of Google Workspace CLI implementing a full MCP server, then deliberately deleting all 1,151 lines of it two days after launch. That investigation revealed an architectural mismatch between MCP's protocol design and large-scale APIs.

But that was only one data point. Since publishing that article, I discovered two more — and together, they tell a much bigger story about where AI agent architecture is heading in 2026.

The Timestamp Hack: Before MCP Had a Name

In early 2024, I was working on an AI assistant for my company's medical IT platform. We serve clinics across the Kansai region of Japan (Osaka, etc.) — and I'd been using ChatGPT's Custom GPTs to prototype workflows.

I had a simple need: I wanted every AI response to include the exact timestamp of when the conversation happened. Not for fun — for traceability. In medical IT, knowing when a decision was discussed matters. It matters for audits. It matters for compliance. It turned out to matter for patent applications too.

Here's what I did. I deployed a tiny Web API on a server we host publicly. It did exactly one thing: return the current time. Then I configured the Custom GPT to call this API before every response, and output the timestamp first.

The result looked like this:

User: Hey, long time no see!
(Communicated with myowndomain.com)

🕐 Response time: 2025-04-02 09:39:00 (JST) / 2025-04-02 00:39:00 (UTC)

Oh wow, it's been a while! So great to hear from you! 😊

A web API that returns a timestamp. Called before every response. Output deterministically. Nothing more, nothing less. That's all it did.

At the time, this was called "Function Calling" or "Tool Use" — the predecessors to what Anthropic would later formalize as MCP in November 2024. I didn't know I was implementing a pattern that would become the center of a protocol war. I just needed a clock.

But here's what matters: the design decision I made instinctively was to keep the external call as small and deterministic as possible. One API. One purpose. Minimal payload. The LLM didn't need to understand time zones or server infrastructure — it just needed to paste the result.

It wasn't a "hack" because I was lazy. It was an architectural instinct: keep the LLM away from what the system already knows. Deterministic output for a deterministic need. Don't make the AI think about the time — just give it the time.

Looking back now, eighteen months later, it turns out this minimal pattern — one deterministic call, zero reasoning overhead — was already the architecture that the rest of the industry would independently converge on. I didn't see it that way at the time. I was just solving a problem.

The MCP Honeymoon — And the Hangover

November 2024. Anthropic open-sourced MCP. By February 2025, Google and others rushed to announce MCP support. The community was electric. Finally, a standard protocol for connecting LLMs to external tools!

I dove in immediately. I connected MCP servers for GitHub, for databases, for various services. Context windows were getting larger. The future felt bright.

And at first, it was genuinely impressive. GitHub operations that used to require manual terminal commands — commits with thoughtful messages, PR creation, branch management — the AI handled them smoothly through MCP. I felt the productivity gains. They were real.

But then something else started happening.

The AI started getting... dumber.

Not in the "wrong answer" sense. In fact, the AI got better at executing tasks exactly as intended — MCP meant it could commit code, create PRs, and query databases with precision. But something subtler was degrading. The quality of reasoning. The ability to take a vague idea and turn it into a structured thought. What I call "zero-to-one thinking" — the creative, synthetic part of working with an LLM.

I spent the second half of 2025 with this nagging feeling. More tools, more capabilities, but less... intelligence. More precise in execution, less insightful in thought. I kept thinking: "I wish context windows would just get bigger so this wouldn't matter." But I also suspected that bigger windows alone wouldn't fix it — the AI would probably just get confused in different ways.

I couldn't quantify this feeling at the time. But I now know that researchers were documenting exactly what I was experiencing.

The Science Behind "Getting Dumber"

It turns out my gut feeling had a name: context rot.

Here's what researchers found — and why it matters for anyone loading MCP servers into their workflow:

Research	Key Finding
Context Rot (Chroma Research)	Irrelevant context degrades reasoning first. Retrieval survives; thinking dies.
Reasoning Degradation with Long Context Windows (14-model benchmark)	Reasoning ability decays as a function of input size — even when the model can still find the right information.
Maximum Effective Context Window (Paulsen, 2025)	The actual usable window is up to 99% smaller than advertised. Severe degradation at just 1,000 tokens in some top models.
Fundamental Limits of LLMs at Scale (arXiv, 2026)	Context compression, reasoning degradation, and retrieval fragility are proven architectural ceilings — not bugs to be patched.

Let me unpack why this hits MCP users so hard.

Chroma Research showed that as irrelevant context increases in an LLM's input, performance degrades — and the degradation is worse when the task requires genuine reasoning rather than simple retrieval. The less obvious the connection between question and answer, the more devastating the irrelevant context becomes.

The "Challenging LLMs Beyond Information Retrieval" study tested 14 different LLMs and demonstrated that reasoning ability degrades as a function of input size — even when the model can still find the right information. Information retrieval and reasoning are different capabilities, and reasoning breaks first.

And here's the connection to MCP that makes this personal:

A single popular MCP server like Playwright contains 21 tools. Just the definitions of those tools — names, descriptions, parameter schemas — consume over 11,700 tokens. And these definitions are included in every single message, whether you use the tools or not.

Now multiply that by 10 MCP servers. You've burned 100,000+ tokens on tool definitions alone. Your 200k context window is suddenly 70k. And it's not just smaller — it's polluted with information that actively degrades the model's ability to reason about the thing you actually asked it to do.

This is what I felt. The AI wasn't broken. It was drowning. More tools meant more noise in the signal. More capability meant less room to think.

The 15,000-Character Prompt and the Limits of "Prompt Engineering"

While I was wrestling with MCP overhead, I was also building an AI-powered tool — essentially a converter that takes ambiguous, unstructured text input and generates structured, formatted output. Think of it as a bridge between how humans naturally communicate and how systems need to receive data.

The core of this tool is a system prompt. That prompt went through dozens of iterations. At its peak, it was 20,000 characters. I tested, compared outputs, and eventually settled on 15,000 characters.

15,000 characters of instructions. For a single task.

The whole time, a thought kept nagging me: "Would a human expert need 15,000 characters of instructions to do this job?" A domain specialist would need maybe a paragraph of guidance. The rest is knowledge they already have — accumulated through years of working in their field.

And that's when "prompt engineering" started feeling like what it really was: a brute-force workaround for the absence of domain expertise in the model's operating context.

But here's the twist. Despite the bloated prompt, the tool worked. Output quality stayed consistent and reliable. Why?

Because I had constrained the domain. The tool operated within a specific industry workflow — a narrow slice of reality with its own vocabulary, its own established patterns, its own expected output formats. By telling the LLM upfront "you are operating within this domain," the massive prompt became effective.

If you've ever worked with LLMs, you already know this intuitively: a purely descriptive, narrative-style prompt — no matter how long — doesn't guarantee output quality. We've all been there. But a prompt that constrains the domain changes the game.

Here's why, and you don't need a PhD to see it. Think about what's happening inside a Transformer model. The attention mechanism operates on an enormous matrix — in large models, tens of thousands of dimensions. Every token is trying to figure out which other tokens matter. When the domain is wide open, the model is searching for relevance across a vast, noisy space. The outputs fluctuate. The reasoning wanders. Anyone who's done even basic linear algebra — even 3×3 matrices in high school — can imagine what happens when you scale that uncertainty to tens of thousands of dimensions. Of course the output changes every time.

But constrain the domain, and you dramatically narrow where the model needs to look. The relevant vectors cluster. The gap between what the model retrieves and what the human intended shrinks toward zero. Domain limitation doesn't just help. It's the mechanism by which prompts actually work.

This taught me something that would later click into place: domain limitation is the real optimization. Not longer prompts. Not bigger context windows. Narrower scope.

And if that's true for prompts, shouldn't the same principle apply to how we design AI agents?

From Prompt Engineering to Architecture Engineering

As the tool matured, the architecture evolved in a direction I didn't fully appreciate at the time.

The initial version was pure prompt — a single, monolithic instruction set that did everything through LLM reasoning. Unstructured text in, structured text out.

But the real world isn't one output format. My domain required multiple types of structured documents — each with its own format, its own required fields, its own regulatory and compliance requirements. The number of output variations kept growing.

Trying to handle all of these through prompt engineering alone was... well, it was exactly the "spread the entire menu on the table" problem from Part 1.

So the architecture shifted. The LLM's output became fully structured JSON — deterministic, parseable, machine-readable. Document generation moved to Google Workspace via GCP. The LLM's job narrowed to what it's actually good at: understanding the input, extracting the meaning, structuring the reasoning. Everything else — formatting, template selection, compliance checks, document assembly — moved to deterministic systems.

The LLM handles the ambiguous. Deterministic systems handle the deterministic.

I was doing this throughout 2025, iterating toward an architecture where AI reasoning and programmatic execution were cleanly separated. And I kept thinking about Google Workspace — if only there were a way to programmatically drive every Workspace API from the command line, it would be the perfect backend for the document generation pipeline...

And Then GWS Appeared

March 2026. Google released gws — Google Workspace CLI. A Rust-based CLI that covers nearly every Google Workspace API, with commands dynamically generated from Google's Discovery Service.

When I saw the announcement, my reaction was immediate: "This is it. This is what I've been waiting for."

A CLI that could drive Gmail, Drive, Docs, Sheets, Calendar — all from the command line, all returning structured JSON. Perfect for my document generation pipeline. Perfect for AI agent integration.

And then I noticed the articles mentioning MCP support. Perfect! I could connect it directly to—

$ gws mcp
{
  "error": {
    "code": 400,
    "message": "Unknown service 'mcp'."
  }
}

You know the rest. That investigation became Part 1. Google had implemented a full MCP server — 1,151 lines of Rust — then deliberately deleted it as a breaking change. Two days after launch.

At the time, I focused on the forensic story: what happened, why, and what it meant for tool design. But the deeper significance only hit me later.

Google didn't just remove MCP. Google arrived at the same architectural conclusion I had been groping toward with my own product — that for large-scale operations, the right pattern is CLI-first with structured output, not protocol-mediated tool discovery. "Order from the kitchen when you're hungry" beats "spread the entire menu on the table."

That was two independent arrivals at the same destination.

Then I found the third.

The Hackathon Winner's Blueprint

A few days after publishing Part 1, I came across the everything-claude-code repository by Affaan Mustafa (@affaanmustafa). Affaan won the Anthropic × Forum Ventures hackathon in NYC, building zenith.chat entirely with Claude Code in 8 hours. His repository — 77,000+ stars, 640+ commits, 76 contributors — packages 10+ months of daily Claude Code usage into a complete agent configuration system.

I started reading it out of curiosity. Within minutes, I was sitting bolt upright.

The philosophy was identical to what I'd been building independently.

Let me show you the parallels.

MCP: Deliberately Minimized

From Affaan's guide:

"Your 200k context window before compacting might only be 70k with too many tools enabled."

His rule of thumb: have 20–30 MCPs configured, but keep under 10 enabled and under 80 tools active. The repository includes mcp-configs/mcp-servers.json with explicit disabledMcpServers entries — actively turning off MCP servers to protect context space.

This is exactly what Google concluded with gws. And exactly what I experienced — more tools, less thinking room.

CLI Skills as MCP Replacements

From Affaan's longform guide:

"Instead of having the GitHub MCP loaded at all times, create a /gh-pr command that wraps gh pr create with your preferred options. Instead of the Supabase MCP eating context, create skills that use the Supabase CLI directly. The functionality is the same, the convenience is similar, but your context window is freed up for actual work."

Skills in Claude Code are Markdown files — tiny prompt templates that load only when invoked. A /gh-pr skill might be 200 tokens. The GitHub MCP server's tool definitions are thousands. Same functionality. Orders of magnitude less context consumption.

This is the "kitchen model" from Part 1, independently rediscovered by a power user.

Domain Expert Agents

The repository is organized into specialized subagents: planner.md, code-reviewer.md, tdd-guide.md, security-reviewer.md, build-error-resolver.md. Each agent has a narrow scope, specific tools, and defined behaviors.

This mirrors what I learned from my own product development — that established industries organize into specialties for a reason, and AI should follow the same principle. You don't ask a generalist to do a specialist's job. You don't ask a general-purpose agent to handle security review when a specialized security-reviewer agent would be more precise and use less context.

Context Hygiene as First Principle

Affaan's system includes automatic compaction hooks, session memory persistence, and strategic context management. The entire architecture is built around one principle: protect the context window for reasoning.

Not storage. Not tool definitions. Reasoning.

The Convergence

So here's what happened in 2026:

Google — a trillion-dollar company with the largest productivity API surface in the world — implemented MCP, stress-tested it against 200–400 tool definitions, and deleted it. Their conclusion: CLI-first with on-demand schema discovery. Context stays clean.

Affaan Mustafa — an individual developer who won an AI hackathon and spent 10+ months refining his workflow — independently concluded that MCP should be minimized, replaced with CLI skills where possible, and the context window should be protected for reasoning above all else.

I — a medical IT veteran building AI-powered tools in Japan — arrived at the same architecture through a completely different path. A timestamp API in 2024. The "getting dumber" experience in 2025. A product's evolution from monolithic prompt to JSON + deterministic pipeline. And then the forensic discovery of Google's MCP deletion.

Three different starting points. Three different domains. Three different scales. The same conclusion.

That's not coincidence. That's a phase transition.

What the 2026 Phase Transition Actually Means

When people talk about AI milestones, they usually mean model capabilities. GPT-4. Claude 3. Gemini Ultra. Bigger context windows. Better benchmarks.

But the real phase transition of 2026 isn't about model capabilities. It's about how we architect around the capabilities we already have.

The shift can be summarized in one sentence:

"Do it for me" is expensive. "Do this specific thing" is cheap.

Every token spent on tool definitions, prompt engineering, and ambiguous instructions is a token not spent on reasoning. And the research confirms what practitioners have been feeling: irrelevant context doesn't just waste space — it actively degrades the model's ability to think.

Here's what that means in practice:

The end of "prompt engineering" as we knew it. A 15,000-character prompt is a confession that we're compensating for missing architecture. The future is narrower prompts, domain-specific skills, and deterministic systems handling everything that doesn't require reasoning.

MCP is not dead — it's bounded. MCP remains excellent for small-to-medium tool sets (under 50 tools). But for large API surfaces, CLI-first is the proven pattern. The "everything via MCP" fantasy is over.

"Skills" are the new unit of AI agent design. Whether you call them Skills (Affaan), Agent Skills (Google), or domain-specific prompts (what I've been doing with my own tools), the pattern is the same: small, scoped, loaded on demand, discarded after use.

Context windows are not memory — they're working memory. Treating the context window as storage is like covering your entire desk with every book you own before you even pick up a pen. You haven't left any room to actually write. The desk needs to be clear for thinking — and every MCP tool definition, every bloated prompt, every retained conversation turn is another book on the pile.

The Human Parallel (Or: Why "Do It For Me" Was Always Expensive)

There's an observation I keep coming back to, and it's one that makes me laugh every time.

Consider how humans delegate work:

Boss: "Handle this, will you?"
Employee: (Internal monologue: What exactly? By when? In what format? Who approved this? What's the budget?) → 10 rounds of clarification follow.

Now consider the alternative:

Boss: "Run git commit -m 'fix: resolve auth timeout' && git push origin main."
Employee: Done. One round. Zero ambiguity.

The first conversation — the "human" one — requires the employee to infer intent, plan actions, select tools, estimate parameters, and verify assumptions. Every step of that inference costs time and mental bandwidth.

In LLM terms, every step of that inference costs tokens.

MCP tool definitions are the LLM equivalent of "let me explain everything you might possibly need to know before we start." CLI commands are the equivalent of "just do this one thing."

What the token economy has done — accidentally, beautifully — is make the cost of human communication ambiguity visible as a number. Every vague instruction, every "you know what I mean," every "figure it out" translates directly to token consumption that crowds out actual reasoning.

Someone with forty-plus years of programming experience — from assembly language to LLMs — finds this deeply ironic. We spent decades making computers understand human language. Now we're learning that the most efficient way to use language-understanding computers is... to give them precise, unambiguous commands. Like assembly language. Like CLI.

The wheel doesn't just turn. It circles back to the truth.

What Comes Next

If the pattern holds, the next phase is already emerging.

Domain-specific agent languages. Not natural language prompts. Not traditional programming languages. Something in between — structured enough for deterministic execution, flexible enough for AI reasoning. We're already seeing DSLs for agent workflows (LangGraph's graph definitions), constrained syntax languages designed for LLM generation, and YAML/JSON-based knowledge objects.

Agent architecture as a discipline. "Prompt engineer" was the job title of 2024. The 2026 equivalent is closer to "Agent Architect" or "Domain Skill Designer" — someone who understands how to decompose workflows into deterministic and non-deterministic components, and how to allocate context window real estate accordingly.

Domain specialization as a design principle. This is my domain bias speaking — I come from medical IT, where specialization has been refined over centuries. There's a reason medicine has cardiologists and dermatologists. It isn't bureaucratic — it's cognitive. A specialist holds deep domain knowledge that makes their work faster, more accurate, and more reliable. I believe AI agents should be organized the same way. Not one giant model that knows everything. A team of specialists, each with their own skills, routing tasks to the right expert. Every industry has its own version of "specialties." The principle is universal.

Closing

In Part 1, I wrote: "If you write about an OSS tool, run it first."

In Part 2, the lesson is different:

If three independent paths converge on the same conclusion, pay attention.

Google didn't read Affaan's guide before deleting MCP from gws. Affaan didn't study my architecture before recommending CLI skills over MCP. I didn't know about either of them when I built a timestamp API in 2024 and started separating deterministic from non-deterministic processing.

We all arrived at the same place: protect the context window for reasoning. Push everything deterministic to CLI, scripts, and structured pipelines. Load skills on demand. Discard them when done. Let the AI think.

That convergence — from a trillion-dollar company, a hackathon winner, and someone who's been writing code since assembly language was the only option — is what makes 2026 a phase transition.

Not because the models got better. Because we finally learned how to stop wasting them.

Try It Yourself

If you want to feel what "the 2026 phase transition" means in practice rather than just reading about it, the fastest way is to inject Affaan's system into your own Claude Code environment.

I did it myself. The difference was immediate — sessions stayed coherent longer, context stopped rotting mid-task, and the AI's reasoning felt sharper in ways that are hard to quantify but impossible to miss once you've experienced them.

The quickest path — install as a Plugin directly inside Claude Code:

# Inside Claude Code
/plugin marketplace add affaan-m/everything-claude-code
/plugin install everything-claude-code@everything-claude-code

That alone gives you the commands, skills, and hooks. You'll notice the difference.

For the full setup including rules and language-specific configurations:

git clone https://github.com/affaan-m/everything-claude-code.git
cd everything-claude-code
./install.sh typescript   # or: python / golang / rust

You don't need to install everything. Start with the plugin. Use it for a day. Pay attention to how long your sessions stay productive before context degrades. Compare it to yesterday.

I suspect you'll have your own moment of convergence — your own version of the realization that Google, Affaan, and I all had independently. That the bottleneck was never the model. It was how much of the context window we were wasting on everything except thinking.

Your setup is different from mine. Your domain is different. But the principle is the same.

Let the AI think.

And if this feels familiar —

it is.

References

Part 1: Not Everything Needs MCP — What Google Workspace CLI Taught Us About AI Agent Architecture
everything-claude-code by Affaan Mustafa — The agent harness performance optimization system
The Shorthand Guide to Everything Claude Code — 2.7M+ views on X
The Longform Guide to Everything Claude Code — Token optimization, memory persistence, and CLI skill patterns
Chroma Research, "Context Rot" — Empirical study on how irrelevant context degrades LLM performance
"Challenging LLMs Beyond Information Retrieval: Reasoning Degradation with Long Context Windows" — 14-model benchmark showing reasoning decay with context length
Paulsen (2025), "Context Is What You Need: The Maximum Effective Context Window for Real World Limits of LLMs" — Maximum effective context windows far smaller than advertised
"On the Fundamental Limits of LLMs at Scale" (2026) — Formal framework for reasoning degradation under context expansion

Not Everything Needs MCP: What Google Workspace CLI Taught Us About AI Agent Architecture

Gen.Y.Sakai — Mon, 09 Mar 2026 08:35:52 +0000

Menu on the Table vs Order from the Kitchen — Why CLI Beats MCP for Large APIs

When Google Workspace CLI launched, several articles mentioned its MCP server.

But when I tried to run gws mcp, something strange happened.

The command didn't exist.

What followed was a deep forensic investigation — from README to source code to git history — that ended with a discovery: Google implemented a full MCP server, improved it, then deliberately deleted all 1,151 lines of it as a breaking change. Two days after launch.

This is the story of that investigation, and what it reveals about AI agent tool design.

What is Google Workspace CLI?

Google Workspace CLI (gws) is a Rust-based CLI tool that covers nearly every Google Workspace API. It's open source under Apache 2.0 and installs via npm:

npm install -g @googleworkspace/cli

Its killer feature: commands are dynamically generated from Google's Discovery Service at runtime. Unlike traditional CLI tools that hardcode commands for each API, gws reads the Discovery Document and builds its command surface on the fly. When Google adds a new Workspace API endpoint, gws picks it up automatically — zero maintenance required.

gws drive files list --params '{"pageSize": 10}'
gws gmail users messages list --params '{"userId": "me"}'
gws calendar events list --params '{"calendarId": "primary"}'

Every response is structured JSON. It ships with 100+ Agent Skills — not just prompt templates, but complete workflow definitions covering auth, safety, and API usage patterns. In short, gws is built as a runtime for AI agents to operate Google Workspace, not just a tool for humans.

Keep this architecture in mind. It's the key to understanding why MCP was removed.

"MCP Server Included" — Or So the Articles Said

Within hours of launch, tech publications ran with it:

"It also includes an MCP server mode through gws mcp"
— VentureBeat

"MCPサーバーを起動することができ、Claude Desktop、Gemini CLI、VS CodeなどのMCP対応クライアントからGoogle Workspace APIを直接呼び出すことができる"
A Japanese tech publication made a similar claim, saying that the CLI could start an MCP server and be used from Claude Desktop, Gemini CLI, and VS Code.
— Japanese tech publication

MCP (Model Context Protocol) is arguably the hottest protocol in the AI agent ecosystem right now. Originally proposed by Anthropic for Claude, then donated to the Linux Foundation, it's being adopted by Claude Desktop, Gemini CLI, VS Code, Cursor, and many others.

"Google Workspace supports MCP" was exactly the kind of news the community was waiting for.

So I tried it immediately.

The Wall: `gws mcp` Doesn't Work

$ gws mcp
{
  "error": {
    "code": 400,
    "message": "Unknown service 'mcp'. Known services: drive, sheets, gmail, 
    calendar, admin-reports, reports, docs, slides, tasks, people, chat, 
    classroom, forms, keep, meet, events, modelarmor, workflow, wf.",
    "reason": "validationError"
  }
}

gws interprets its first argument as a Google API service name. mcp isn't a service, so it fails. Fair enough — maybe the syntax is different?

$ npx -y @googleworkspace/cli mcp   # Same error
$ gws --help                         # No mention of mcp anywhere
$ gws mcp --help                     # Same error

The --help output lists exactly three top-level commands: schema, generate-skills, and auth. MCP is nowhere to be found.

Something was off.

Dissecting the npm Package

I looked at what was actually installed:

$ readlink -f "$(which gws)"
.../node_modules/@googleworkspace/cli/run-gws.js

The entry point is a Node.js wrapper that downloads and runs a prebuilt Rust binary. Checking package.json:

{
  "bin": {
    "gws": "run-gws.js"
  },
  "version": "0.8.1"
}

The only binary exposed is gws. No gws-mcp, no gws-server. The supportedPlatforms section confirms: every platform ships a single binary named gws.

The MCP entry point simply doesn't exist in the distributed package.

Reading the Rust Source

Maybe MCP exists in the repo but isn't included in the npm release? I cloned the repository and read src/main.rs:

async fn run() -> Result<(), GwsError> {
    let args: Vec<String> = std::env::args().collect();
    // ...
    if first_arg == "schema" { /* ... */ }
    if first_arg == "generate-skills" { /* ... */ }
    if first_arg == "auth" { /* ... */ }
    // Everything else → treat as service name
    let (api_name, version) = parse_service_and_version(&args, &first_arg)?;
}

Three top-level commands. Everything else falls through to service name resolution. No mcp branch exists. The print_usage() function doesn't mention MCP. The mod declarations don't include mcp_server.

I built from source to confirm:

$ cargo build
$ ./target/debug/gws mcp
→ Same error

At this point I had confirmed across five layers:

gws --help — no MCP
gws mcp — unknown service
package.json — bin is gws only
main.rs — no MCP branch
Fresh build from source — still no MCP

MCP doesn't exist. Not in the release. Not in the source.

But the Traces Were There

I wasn't ready to give up. I grepped the repo:

$ grep -R "mcp" .
./.github/labeler.yml:"area: mcp":
./.github/labeler.yml:          - src/mcp_server.rs
./CHANGELOG.md:- dd3fc90: Remove mcp command
./CHANGELOG.md:- 9cf6e0e: Add --tool-mode compact|full flag to gws mcp.
./CHANGELOG.md:- 670267f: feat: add gws mcp Model Context Protocol server

There it was.

The CHANGELOG told a clear story: MCP was implemented, improved, and then removed.

GitHub Issues search returned 19 results for "MCP" (7 open, 12 closed):

gws mcp -s does not exist (#69)
MCP server ignores GOOGLE_WORKSPACE_CLI_ACCOUNT env var (#221)
MCP tools/list returns uncallable tool names (#162)
Switch MCP tool names from underscore to hyphen separator (#235)
feat: add tool annotations, deferred loading, and pagination to MCP server (#260)

These aren't wishlist items. These are real bug reports from real users who were running the MCP server. You don't debate underscore vs hyphen in tool names unless you're actually calling those tools.

MCP wasn't missing. It was there, and it was deleted.

The Moment of Deletion: 1,151 Lines Gone

I found the commit:

$ git show --stat dd3fc90
commit dd3fc9074d74a3c74792aa08c6bff7a9984d0d46
Author: Steve Bazyl <sqrrrl@gmail.com>
Date:   Fri Mar 6 13:33:23 2026 -0500

    fix!: Remove MCP server mode (#275)

    * BREAKING CHANGE: Remove MCP server mode
    * Add changeset file

 .changeset/no-mcp.md |    5 +
 README.md            |   34 ----
 src/main.rs          |    6 -
 src/mcp_server.rs    | 1151 --------------------------------------------------
 5 files changed, 5 insertions(+), 1192 deletions(-)

March 6, 2026. Two days after launch.

The ! in fix!: is Conventional Commits syntax for a breaking change. This wasn't a quiet deprecation — it was a deliberate, loud removal.

src/mcp_server.rs — 1,151 lines deleted. This was no prototype. It was a complete MCP server implementation: JSON-RPC protocol handling, tools/list for tool discovery, tools/call for tool execution, Discovery API integration.

The area: mcp label was also removed from AGENTS.md. The next day, Issue #260 (proposing tool annotations and deferred loading for the MCP server) was closed as not_planned.

This wasn't a temporary retreat. It was a policy decision.

Why Google Removed MCP

The answer lies in the collision between MCP's protocol design and Google Workspace API's scale.

The tools/list Problem

In MCP, when a server starts up, it exposes all available tools via tools/list. The client's LLM loads these tool definitions into its context window to decide which tools to use and when.

Google Workspace API is massive. Drive, Gmail, Calendar, Sheets, Docs, Chat, Tasks, People, Forms, Admin — over 10 major services, each with dozens of methods. Drive alone has files.list, files.get, files.create, files.update, files.delete, permissions.create... easily 10+ methods.

Run all of that through Discovery API and you get 200–400 MCP tools.

The CHANGELOG confirms this:

Add --tool-mode compact|full flag to gws mcp. Compact mode exposes one tool per service plus a gws_discover meta-tool, reducing context window usage from 200-400 tools to ~26.

That's 2–8x the practical limit for most MCP clients (typically 50–100 tools).

Context Explosion

200–400 tool definitions, each with name, description, parameter schemas, and required/optional markers, all serialized as JSON and loaded into the context window. Estimated token cost: 40,000–100,000 tokens — just for tool definitions.

That leaves dramatically less room for user instructions, conversation history, and actual reasoning. Latency increases. Inference quality degrades.

Compact Mode Didn't Save It

The team tried. Compact mode reduced the tool count to ~26 by exposing one meta-tool per service. But MCP was deleted the day after compact mode was implemented. That tells you the mitigation wasn't sufficient.

Bug Avalanche

During MCP's brief existence, at least 7 bug fixes were needed:

Tool naming ambiguity (fixed twice)
Schema inconsistencies in tool calls
Alias vs Discovery Document name mismatch
unwrap() panics in mcp_server.rs
Auth environment variable being ignored
Empty body: {} on GET methods causing 400 errors

For a small OSS project, that's an unsustainable maintenance burden over just two days.

The Root Cause: Architectural Mismatch

The bug count alone didn't kill MCP. The real issue is structural.

Google Workspace API is optimized for dynamic generation of hundreds of methods via Discovery Service. That's its superpower as a CLI — new APIs appear automatically, no code changes needed.

But that same superpower becomes a liability under MCP. MCP's tool model requires all tool definitions to be sent upfront to the client. "Dynamically generate hundreds of methods" directly translates to "flood the context window with hundreds of tool schemas."

This isn't a fixable bug. It's a fundamental mismatch between Google's API design and MCP's protocol design.

MCP was technically implementable. But it couldn't be shaped into a feature that justified its implementation complexity.

The Architecture After MCP: CLI-First

Here's what gws looks like now:

Google Workspace APIs
        ↓
    Discovery Service
        ↓
      gws CLI
        ↓
    JSON output
        ↓
  AI Agent (via shell)

This is fundamentally different from MCP.

MCP model: LLM discovers all tools upfront via protocol → calls tools via structured protocol. All tool definitions live in the context window.

CLI model: Agent calls gws as a shell command. Skills and CONTEXT.md guide which commands to run. gws schema provides on-demand schema queries. Context overhead: near zero.

The MCP approach is "spread the entire menu on the table and choose." The CLI approach is "order from the kitchen when you're hungry." For an API surface as vast as Google Workspace, the kitchen model wins.

The 100+ Agent Skills remain. The 50+ curated recipes for Gmail, Drive, Calendar, Docs, and Sheets remain. The structured JSON output remains. The on-demand schema discovery remains.

MCP's removal didn't reduce functionality. The project converged on a more efficient agent integration model that didn't need MCP as a layer.

Were the Articles Verified?

Multiple publications reported "MCP server included" — in English and Japanese. But by the time I checked the repository:

gws --help showed no MCP
gws mcp returned "unknown service"
The npm package exposed only gws in bin
main.rs had no MCP branch
Building from source didn't produce MCP
MCP had been removed as a BREAKING CHANGE two days after launch

The MCP implementation did exist in the repo's history. Issues, PRs, and CHANGELOG entries confirm it was real. So "pure fabrication" would be unfair.

But a responsible technical article needs at least one of: a startup command, a config example, an execution log, or a version number where the feature works. None of the articles I found had any of these.

I use AI as a research partner too — I had ChatGPT help analyze the README and used Claude Code to dig through commit history. AI-assisted research is fine. The problem is publishing AI-generated summaries without running the actual software.

If you write about an OSS tool, run it first. Especially in the first week after launch, when READMEs and released artifacts can be out of sync. That gap is where misleading articles are born.

Will MCP Come Back?

Short term (< 6 months): Unlikely.

Issue #260 was closed as not_planned. PR #275 declared a BREAKING CHANGE. The area: mcp label was removed from AGENTS.md. This isn't a pause — it's a clear signal that MCP is not in the development roadmap.

Medium term (6–12 months): Conditionally possible.

If the MCP specification evolves to address:

Tool count limits — clients efficiently handling hundreds of tools
Lazy loading standardization — on-demand tool discovery as a first-class MCP feature
Community contribution — someone submits and maintains a complete implementation

Long term: Architecture-dependent.

Google currently positions gws as a Gemini CLI Extension. If Gemini's ecosystem adopts a tool integration protocol similar to MCP, something functionally equivalent could emerge.

But the current trajectory is clearly CLI + Skills + on-demand schema discovery. MCP's near-term revival is unlikely.

What This Investigation Revealed

Tool Design in the Age of AI Agents

gws poses an important question about AI agent tool integration.

MCP standardizes tool discovery and invocation at the protocol level. LLMs see all available tools and call them through structured interfaces. This works beautifully for small-to-medium tool sets.

But for services with massive API surfaces like Google Workspace, MCP's model breaks down. Tool definitions consume the context window and degrade reasoning capability.

CLI-based integration lets agents call external tools as shell commands. No tool definitions in the context window. Skills and documentation teach the agent what's available; schemas are queried on demand. Even with hundreds of available operations, context overhead stays near zero.

This isn't MCP vs CLI as a universal choice. The optimal integration method depends on the scale and characteristics of the tool set. Google didn't remove MCP because MCP is a bad protocol. They removed it because Google Workspace API's scale created a structural mismatch with MCP's tool model. For smaller tool sets (10–50 tools), MCP remains one of the best integration approaches available.

The Speed of OSS

gws MCP followed this timeline:

v0.3.x: MCP server added
v0.5.x: compact/full mode improvement
v0.6.x: bug fixes (naming, schemas, auth)
v0.8.x: MCP removed (BREAKING CHANGE)

All of this happened within days. Features can be added and removed faster than articles can be written about them. That's why running the software yourself matters more than reading about it.

CLI = Agent Runtime

Tracing gws's design reveals something about Google's vision for AI agents:

API schema (Discovery Service)
    ↓
CLI runtime (gws)
    ↓
Structured JSON output
    ↓
AI Agent (guided by Skills)

This is "CLI as Agent Runtime." Traditionally, CLI was a human interface. gws is explicitly designed as an interface for AI agents to call. Structured JSON everywhere. 100+ pre-defined Skills. On-demand API schema queries via gws schema. Agent guidelines in CONTEXT.md.

This design philosophy is precisely what made MCP redundant. MCP exposes tools via protocol; gws treats the CLI itself as the tool. No need to send tool definitions over JSON-RPC when you can just execute a shell command.

If this is Google's answer, then the future of AI agents won't be MCP-only. At least for services with large API surfaces, CLI-first will remain a viable — perhaps superior — alternative.

Conclusion

This investigation started with a trivial error: gws mcp returning "unknown service."

I read the README. Checked --help. Opened package.json. Read the Rust source. Built from source. Traced the git log. Examined commit diffs. Searched GitHub Issues. At the end of that trail was 1,151 lines of MCP server code, deliberately removed as a BREAKING CHANGE.

The removal wasn't a technical failure. It was the recognition of an architectural mismatch. Google's Discovery API dynamically generates hundreds of methods — a strength that directly became MCP's context window problem. Compact mode was attempted as a mitigation but couldn't resolve the fundamental collision between Google's API scale and MCP's tool model.

What remains is everything an AI agent needs to operate Google Workspace: 100+ Agent Skills, structured JSON output, on-demand schema discovery — all without MCP.

There's no universal answer to the MCP vs CLI debate. But what gws demonstrated through its own history is that AI agent tool design is still an open problem. The right architecture depends on the shape and scale of the API surface.

If you write about an OSS tool, run it first. Not the README — the actual software. In the age of AI, repository analysis takes hours, not days. Use that speed for verification, not just content production.

Not Everything Needs to Be a Framework: Why Spawning Processes Still Wins

Gen.Y.Sakai — Mon, 15 Dec 2025 07:21:13 +0000

Some people say:

“This is just spawning a subprocess. That’s not architecture.”

They’re absolutely right.

And that’s exactly why it works.

I’ve been shipping production systems long enough to have lived through CORBA, SOAP, WSDL, and every other attempt to make inter-process communication “pure.”

I’ve also shipped systems under real deadlines, in regulated industries, where “rewriting everything” is not an option.

This article is about why the sidecar pattern — yes, literally just wrapping a binary — keeps winning in the real world.

Not in theory.

Not in blog posts.

In production.

The Pattern Everyone Pretends Not to Use

Here’s the pattern:

A TypeScript / Node / Electron app
Spawns a compiled binary (.NET, Rust, Go, C++)
Talks over stdin/stdout, pipes, or a local socket
Lets the OS do process isolation

That’s it.

No service mesh.

No gRPC schema wars.

No “distributed systems” cosplay.

Just a parent process orchestrating a sidecar that does the heavy lifting.

If this sounds “too simple,” good.

That’s the point.

“But That’s Just a Wrapper”

Yes.

VS Code wraps git
VS Code wraps OmniSharp (.NET)
Prisma wraps a Rust query engine
Docker Desktop wraps the Docker daemon
Electron apps wrap platform-native tools every single day

If “just a wrapper” was a design flaw, half of modern developer tooling wouldn’t exist.

The uncomfortable truth is this:

Most successful tools are orchestration layers. Not reinventions.

Why This Pattern Keeps Shipping

Let’s be brutally honest about the real options.

Option 1: Rewrite Everything in TypeScript

Months of work
New bugs in mature code
Worse performance
Now you maintain two versions forever

Great for blog posts.

Terrible for shipping.

Option 2: Native Addons (N-API, node-gyp)

Fast, yes
Also fragile
Node upgrades break you
One segfault kills your entire process
Cross-compilation is pain incarnate

Ask anyone who has maintained native addons long-term.

Option 3: Spawn a Sidecar

Uses existing, battle-tested code
Crashes are isolated
Debugging is obvious (it’s a process)
Cross-platform is manageable
Ships this week, not “someday”

This isn’t laziness.

It’s risk management.

“Architecture Purity” vs Reality

In regulated domains — healthcare, finance, government systems — you don’t get to say:

“Let’s just rewrite the crypto layer.”

You integrate with what already exists:

Vendor SDKs
Legacy libraries
OS-specific APIs
Hardware-backed security modules

The sidecar pattern gives you:

A clean boundary
A failure domain you can reason about
A way to keep modern UX without breaking compliance

That’s not a hack.

That’s professional engineering.

This Is Not a New Idea — It’s the Mature One

We spent decades trying to make IPC “beautiful”:

CORBA
SOAP
Enterprise Service Buses
Endless XML schemas

And what did we learn?

That simple, observable processes beat “perfect abstractions” when systems get large and real humans have to operate them.

Today, spawning a process and talking over stdio feels almost embarrassing — until you realize it’s exactly what we wanted 20 years ago.

When You Should Not Do This

Let’s be clear — this is not a hammer for every nail.

Don’t use this pattern if:

A simple REST call solves your problem
The logic is trivial and low-cost
Latency is measured in microseconds
Your team can’t maintain the sidecar language

Pragmatism cuts both ways.

The Real Lesson

The sidecar pattern isn’t about processes.

It’s about respecting reality:

Existing code matters
Deadlines matter
Failure isolation matters
Shipping matters

If your architecture diagram looks clean but your product never ships, you chose wrong.

I’ll take a “wrapper” that ships over a “pure” system that doesn’t — every time.

Final Thought

If this pattern is good enough for:

Microsoft (VS Code)
Docker
Prisma
The entire Electron ecosystem

It’s probably good enough for your project too.

And if someone says

“That’s just spawning a process,”

Smile.

They just described half of modern software — the half that actually works.

Want to try this pattern yourself?

I put together a minimal proof-of-concept in TypeScript + .NET that shows the full lifecycle management and stdio communication in action. It runs in minutes.

Check out the repo on GitHub → open-rx

Have you ever used the sidecar pattern in production? What worked? What broke?

Drop your war stories in the comments — I read every one.

Transparency note:

The title of this article was generated with NanobananaPro.

The opinions, war stories, and architectural scars are entirely my own.