A recurring theme in Japan’s developer blogging community this week is that the interesting AI engineering work isn’t happening in model training labs — it’s happening in the plumbing around models. Three recent Zenn articles illustrate this from different angles: what to do when you can’t send data to the cloud, what happens when you make one AI review another AI’s writing, and how to keep a dozen-plus autonomous agents from losing their identity and memory.
When the cloud is off the table
The first piece, from a developer at a company called miharuba, opens with a problem familiar to anyone working with regulated or confidential data: you want to use an LLM, but company policy — or plain common sense — forbids feeding client data or internal documents into ChatGPT or similar cloud services. Many organizations either explicitly ban sending internal documents to external AI services or require careful case-by-case judgment before doing so. Yet ignoring AI entirely feels like leaving value on the table.
The author’s response was to build and publish a Udemy course on local LLMs using llama.cpp, walking through the practical stack needed to run models entirely on your own hardware: GPU considerations, context window management, KV cache behavior, and eventually retrieval-augmented generation (RAG) for grounding answers in private documents. This is a useful reminder that “local LLM” isn’t just a hobbyist curiosity for people who want to avoid API bills — for a meaningful slice of the enterprise world, it’s the only compliant way to get LLM benefits at all. The course format itself is notable too: rather than a blog post or GitHub repo, the author chose structured video teaching, betting that there’s unmet demand for a guided, systematic path through local-inference internals rather than scattered documentation.
Using one AI to catch what another AI misses
The second article tackles a subtler and arguably more interesting problem: quality control for AI-generated writing. The author had Claude Code draft a long-form piece, then — somewhat awkwardly, as they admit — brought in OpenAI’s Codex CLI to review it, comparing the outcome to asking a rival firm to proofread your own manuscript.
The key finding is what didn’t work: having the same Claude model review its own output twice in a row still left inconsistencies between sections and typos uncaught. Cross-model review, by contrast, surfaced significant issues in a single pass. The article reports that a cross-model review from Codex CLI produced 18 flagged issues, of which 15 were incorporated into the final text. Perhaps more striking than the volume of catches is what the author considers the single most valuable find: not a prose-quality nitpick, but an operational mistake in the publishing process that got caught before it went live.
This is a small but telling data point in the broader conversation about AI self-review loops. It suggests that model diversity, not just repetition, is what breaks a review out of shared blind spots — the same reason human editorial teams rarely rely on one person to both write and fact-check a piece. For teams building AI-assisted publishing or QA pipelines, cross-model review looks like a cheap, high-leverage habit to adopt, especially for anything going out under your name.
Giving a swarm of agents a memory and a personality
The third piece is the most ambitious of the three. The author is running fifteen Claude Code sessions continuously, not as a demo or sandbox, but as the operational backbone for four actual businesses. At that scale, a practical problem emerges quickly: agents need to retain context and behave consistently over time, without that identity and history becoming tangled or lost between sessions.
To solve this, the author built and open-sourced nenrin (MIT licensed), a layer that separates an agent’s accumulated memory from its persona — the idea being that what an agent remembers and who it is are architecturally distinct concerns that should be composed rather than baked together. The project is distributed as an installable plugin (via a simple marketplace add/install/init flow), and after 48 days of operation the author reports thousands of accumulated memory entries feeding the system.
What’s notable here isn’t the specific memory/persona split so much as the underlying claim: that running many long-lived agents in production is now practical enough that people are hitting — and solving — genuine infrastructure problems, not just prompt-engineering quirks. As more teams move from single-shot AI calls to standing agent fleets, memory management is likely to become as standard a concern as logging or state management in conventional distributed systems.
The common thread
Taken together, these three posts sketch out where a lot of practical AI engineering effort is currently going: not toward bigger models, but toward the surrounding infrastructure — local inference for data you can’t export, cross-model checks for output you can’t fully trust from a single source, and memory architectures for agents that need to persist. None of this is flashy, but it’s the layer where AI actually becomes usable inside real organizational constraints.