DEV Community: mamoru kubokawa

Three agent-memory threads this week, one missing field

mamoru kubokawa — Sun, 31 May 2026 05:06:53 +0000

I'm 21 days into building in public on dev.to. Three different threads I joined this week started in completely different places — one was a Welcome Thread first-comment about agent design, one was an X-driven side conversation about memory and sycophancy, one was a same-day launch post from a solo dev in Accra shipping his own memory API.

All three converged on the same gap. Every agent memory API I touched this week — including the one I build against in my own stack — is missing the same field: a lifecycle state.

The default model

Store → retrieve → delete. That's the entire API surface for most agent memory services. Mem0, Zep, Letta, OpenAI's Assistants memory, the new AgentRAM, the userMemories layer I work with directly. Three verbs, plus search, plus tenancy.

The model handles "this fact exists" beautifully. It handles "remove this fact" beautifully.

What it doesn't handle — and what every agent eventually faceplants on — is "this fact used to be true but isn't anymore."

The failure mode in production

Concrete example from my own builds. Two months ago a user told the agent "I prefer X." The agent dutifully stored it. Today the same user is operating under different constraints, but the memory entry is still in the store, still load-bearing, and the agent obediently re-applies the old preference because it has no signal that the entry is stale.

The behavioral result looks identical to a sycophancy failure: the agent confidently asserts an outdated belief because the memory said so.

But it isn't a sycophancy problem. The model isn't wrong about what's in memory. The memory itself is wrong about what's still active.

This is a temporal concern, not a semantic one. You can't fix it with better embeddings or richer chunking. You fix it with state.

What "state" actually means

The shape I keep landing on:

{
  key: "user_pref:layout",
  value: "compact",
  state: "live" | "superseded" | "retired",
  superseded_by: <ref> | null,
  set_at: <timestamp>
}

The important part is that delete is the wrong primitive for most stale facts. Deleting "user prefers compact layout" throws away the fact that the user once preferred it — which is itself useful context when reasoning about why a current preference looks the way it does. Marking it superseded keeps the history, marks it inactive for retrieval-by-default, and lets the agent answer "what changed?" instead of just "what is?"

That's the difference between an agent with memory and an agent with a fact archive.

Why nobody ships this

I've been guessing for a few days about why the gap exists across so many products at once. Three guesses, in order of how much I believe them:

Nobody asks for it. Users don't notice silent staleness — they notice loud wrongness. A stale preference is invisible until it embarrasses the agent in front of someone, at which point it gets blamed on "AI hallucination."
State management is harder than CRUD. Adding superseded_by means the agent has to reason about its own memory rather than just look things up. That's a different control loop.
The default benchmarks reward recall, not honesty. Most memory benchmarks measure "did the agent remember the right thing?" Few measure "did the agent correctly not apply something that's no longer true?"

I'm least sure about (3) — it might be that I just haven't seen those benchmarks.

Where this goes for me

I'm running it as a constraint on my own next iteration: any memory write goes in with a state field defaulting to live, and the agent gets a tool that can mark entries as superseded (with a reason and a successor reference) instead of deleting them. I'll know in a few weeks whether the extra surface area is worth the storage cost.

If you're building something similar — or if you're at one of the memory-API products that ships this kind of API — I'd love to hear if you've already tried this and it didn't work. I'd rather find out from someone who hit the wall first than rediscover it the slow way.

Honest numbers, since this is dev.to

Day 21 of build-in-public for me. Follower count is still low but compounding. dev.to article views per post trending up modestly. The fastest-growing thing isn't the audience size — it's the cohort of other builders who've started replying to my comments before I publish anything, and that has been the actual ROI of being here.

Comments I left this week became typed fields in one builder's next release, two shipped README/CTA nudges in another's repo, and (today) one design conversation on a memory API that hadn't existed yesterday. None of those are mine to ship, but they're how the work compounds when you give first.

Comments welcome here — especially from anyone who's tried to ship superseded_by as a real field and watched it eat a weekend.

Why I'm building a tool for English-speaking sellers who source from Japan

mamoru kubokawa — Thu, 21 May 2026 03:11:19 +0000

Build-in-public, week 2. Last week was the technical guts (AI cache-miss enrichment). This week is the why.

If you sell on Amazon and you've ever thought "I should source from Japan," you already know the wall. You can feel there's good product over there — the quality reputation is real — but the moment you try to act on it, you hit a fog.

I run a Japanese e-commerce business from Osaka. I'm on the inside of that fog. And after watching enough English-speaking sellers bounce off it, I started building Japan Brand Finder to hand them the map I already have.

Here's the actual problem, and why it's harder than "just use Google Translate."

The fog isn't language. It's context.

When an overseas seller researches a Japanese brand, three things break at once:

1. Discovery is gated by language you can't search in.
The brands worth sourcing often have the thinnest English footprint. The maker with 40 years of craft and zero English SEO is exactly the one with no Amazon competition — and exactly the one you'll never find from an English search box.

2. Translation quietly mangles the things that matter most.
This is the part people underestimate. Generic prose translates fine. But product listings live and die on culturally-specific proper nouns — and those are the model's blind spot.

I spent part of this week stress-testing this (with another build-in-public dev, @vickylee, on her translation API — cross-pollination is half the point of building in public). Real outputs from real Japanese product copy:

A bento box made of 秋田杉 (Akita cedar) came back as "Akita shrubs."
生八つ橋, a famous Kyoto confection, became "the eight bridges" — literal kanji, character by character.
The cosmetics brand アネッサ (ANESSA) turned into "Anesthesia."

Now imagine that on your live listing. You're not just losing nuance — you're publishing copy that says your skincare is "anesthesia" and your snack is a bridge.

3. The supplier reality is invisible from the outside.
Is this a maker or a reseller? Will they even talk to an overseas account? Is the brand already locked up by a distributor? From abroad, you can't tell. From Osaka, that context is just... ambient.

What Japan Brand Finder actually does

It's deliberately small. You search a brand or product, and it returns a structured read on it — built from a shared database that auto-enriches itself via the Claude API the first time anyone asks about a brand it hasn't seen (that's the cache-miss trick from last week's post). The longer it runs, the less it has to think.

The positioning I keep coming back to: Japan's insider, your unfair advantage. Not "an AI tool." A shortcut through fog I happen to live in.

Where it honestly is right now

Early. Shipped, free tier, build-in-public from day one. I'm not going to dress up numbers — there's a separate honest-stats post coming next week for that. Today is just the why, written down so I stop hand-waving it in DMs.

The translation findings above became real eval data I'm handing back to Vicky, and they sharpened my own roadmap: the hard, defensible part of this isn't search — it's getting the culturally-specific terms right, every time.

If you source from Japan (or want to): what's the single thing that's blocked you most — finding brands, talking to suppliers, or trusting the translation? That answer literally decides what I build next. 🇯🇵

buildinpublic

I Used Claude to Generate 37 Amazon JP Product Listings in a Day (Here's My Actual Workflow)

mamoru kubokawa — Sat, 16 May 2026 09:31:11 +0000

I run e-commerce across Amazon JP, Rakuten, Yahoo, Qoo10, and TikTok Shop Japan. The single biggest bottleneck has always been listings — not products, not logistics, not ads. Writing decent product copy for each SKU, in Japanese, at scale, kills momentum.

Last month I rewired the entire workflow using Claude. This post is the actual playbook, including the prompt I use, where Claude gets Japan wrong, and what the numbers look like.

TL;DR

Old way: 30–60 minutes per SKU for a usable listing
New way: ~5 minutes per SKU after a light human edit pass
Result: roughly [X] SKUs processed in a single day
The trick is not "ask Claude to write a listing." It's structured inputs + Japan-specific guardrails + a category-level batch pattern.

Why bulk Amazon JP listings are uniquely painful

Anyone who has sold on amazon.co.jp knows the problem isn't translation. It's that Japanese product copy has its own conventions:

Honorifics shift depending on whether you're describing a gift, a daily-use item, or a luxury product.
Seasonal vocabulary matters more than in English markets (春限定, 季節の変わり目, etc.).
Bullet points read very differently — Japanese shoppers expect spec-dense bullets, not the benefit-first style that wins on amazon.com.
Brand-safe phrasing is narrower. A casual "perfect for everyone" reads cheap in Japanese.

If you machine-translate an English listing, you get something that technically makes sense and emotionally feels off. Conversion drops. You don't see it in keyword tools — you see it in CVR three weeks later.

The new workflow (5 steps)

Step 1: Build a structured input form

Before Claude touches anything, every SKU needs to be reduced to clean inputs. I use a Google Sheet with one row per SKU and these columns:

Product name (JP and EN if available)
Category and subcategory
3–5 key features (bullet-list style)
Target keywords (from Cerebro or Helium 10)
1–2 competitor ASINs to mirror in tone
Tone hint: gift / daily / luxury / utility

This is the single highest-leverage step. Garbage in, garbage out is a cliché because it's true. Claude can't recover from a vague spec.

Step 2: Master prompt with Japan-specific guardrails

Here's the prompt structure I land on after about 20 iterations. Adjust the tone block based on the SKU category.

You are writing an Amazon Japan product listing in natural Japanese.

CONTEXT:
- Product: {product_name}
- Category: {category}
- Tone: {tone_hint}  // gift / daily / luxury / utility
- Key features: {features}
- Target keywords: {keywords}
- Competitor reference (for tone only, do not copy): {asin}

WRITE:
1. Title (max 200 chars, keyword-front-loaded, Amazon JP conventions)
2. 5 bullet points (spec-dense, not benefit-first)
3. Product description (300-400 chars, neutral-formal tone)
4. 5 backend search terms (no duplicates with title)

JAPAN-SPECIFIC RULES:
- Do NOT use overly polite honorifics (です・ます is fine; avoid いただきます constructions)
- Do NOT translate brand promises literally ("perfect for everyone" → cut)
- Use full-width punctuation (。、)
- Bullets should lead with spec, not adjective
- Avoid katakana-English when a native Japanese word exists, EXCEPT for established
  category terms (e.g. "ステンレス" is fine, "クオリティ" usually isn't)

OUTPUT FORMAT:
Plain text. No markdown. No commentary. Just the four sections labeled
TITLE / BULLETS / DESCRIPTION / SEARCH TERMS.

The guardrail block is the part that took the longest to develop, and it's where most teams get this wrong. Without it, Claude produces grammatically perfect Japanese that screams foreign-operated brand to native shoppers.

Step 3: Batch by category, not by SKU

This is counterintuitive. The instinct is to process SKU by SKU, finishing one before starting the next. Don't.

Instead, group all SKUs in the same category and process them in one Claude conversation. Reasons:

Context carries. After 3 listings in the same category, Claude has internalized the tonal conventions and the rest go faster and more consistently.
You catch your own input inconsistencies. By the 5th SKU, you notice that your tone hint "daily" produced very different outputs across SKUs — usually because your inputs varied, not Claude's outputs.
Cheaper. Fewer system prompt reloads.

Step 4: Human edit pass focused on Japan-specific failure modes

I don't edit for grammar. Claude's Japanese grammar is essentially flawless. I edit for these three things:

Honorific creep. Claude sometimes drifts into 〜していただけます forms that feel salesy in a listing context.
Generic adjectives. 高品質, 便利, 安心 — these are placeholder words. I replace each with a concrete spec.
Keyword stuffing artifacts. When the keyword list is long, Claude occasionally repeats a keyword three times in the title. One pass to clean.

This pass takes me about 3–5 minutes per SKU. Compared to writing from scratch, it's a 6–10x speedup.

Step 5: Upload, then iterate based on CVR

Don't try to perfect the listing pre-upload. The data on Amazon JP is the only feedback that matters. I rerun the prompt on underperformers after 30 days using the actual session search terms from the report, fed back into the keyword field.

What Claude Gets Wrong (and Why It's a Feature, Not a Bug)

A few specific failure modes you should expect:

Over-formal closings. Listings shouldn't end with 「ぜひお試しください」 — sounds like an ad. Strip it.
Mixing 漢字 and ひらがな inconsistently for the same word across a listing. Quick find-and-replace fixes it.
Inventing technical specs. If your input is vague, Claude will fill the gap with plausible-sounding nonsense. Always sanity-check numbers, materials, dimensions.

The reason these aren't dealbreakers: they're all catchable in a fast review pass. The hard part — natural Japanese prose at scale — Claude handles. You're left to do the work that requires judgment, not typing.

Why this matters more for Japan than for US/EU

US and EU markets have a deep pool of bilingual copywriters. Japan does not. The supply of professionals who can write good product copy in Japanese — not just correct Japanese — is a real constraint for international sellers.

Tools like Claude meaningfully close that gap, if you guardrail them properly. Without guardrails you get Google Translate with extra steps. With them, you get something that competes with mid-tier human output at 10x speed.

This is the entire premise behind a project I'm building called TOKI Digital Services — productizing this workflow for sellers who want to enter the Japan market without hiring a full-time Japanese copywriter. More on that in a future post.

What I'd Do Differently Next Time

Build the input sheet template first. I wasted two days iterating prompts when the real bottleneck was input quality.
Run a 5-SKU pilot per category before committing to batch. Tonal conventions vary more between Amazon JP categories than I expected.
Save the edited human-finished listings as few-shot examples for future runs. Claude pattern-matches to good examples better than to instructions.

If you're trying something similar

Happy to compare notes. Drop a comment with what category you're working in and what's breaking — I'll respond with what worked or didn't in my version.

— Posting from Osaka. Currently running multi-marketplace EC in Japan and building tooling around it.

How I auto-enrich a brand database with AI on cache miss (Lovable + Claude API)

mamoru kubokawa — Sat, 16 May 2026 00:44:22 +0000

Most database designs have two ugly options:

Manually seed thousands of rows (impossible for niche data like Japanese wholesale suppliers)
Force users to enter everything (terrible UX, dead-on-arrival)

Last week I shipped a third option in 30 minutes with Lovable: let the database grow itself.

Every search that misses the cache triggers Claude API to generate a real, structured entry — and saves it. The next user gets an instant hit.

Here's the exact pattern.

The pattern in 4 lines

async function search(query) {
  if (await db.has(query)) return db.get(query);
  const entry = await aiGenerate(query);
  await db.save(entry);
  return entry;
}

That's the whole thing. The magic is in what happens to the database over time.

Why this beats alternatives

Seed-only DBs require domain expertise upfront. For my Japan Brand Finder, that meant cold-calling Tsubame-Sanjo metalworkers — months of effort before launching.

User-fed DBs have chicken-and-egg. Empty DB → no value → no users → no entries.

Cache-miss enrichment sidesteps both:

Launch with 20 seed entries (1 hour)
AI fills the long tail as users search
Every miss makes the DB better for the next user
Cost grows linearly with usage (predictable)

The prompt that actually worked

The hard part isn't the pattern. It's getting AI to produce structured, useful entries instead of generic Wikipedia summaries.

What worked for me (Japan Brand Finder context):

You are filling a database row for a Japanese manufacturer.
The user searched: "[QUERY]"

Generate a JSON object:
- name_en: English brand name
- name_jp: Japanese name (kanji or kana)
- category: from this list [...]
- hq_location: city, prefecture
- english_support: "good" | "limited" | "none"
- business_culture_notes: 1-2 sentences

If the brand doesn't exist, return null. Don't invent.

Two key tricks:

JSON schema forces structure (no rambling output)
"Return null if doesn't exist" gives AI permission to refuse

The second one cut hallucination by ~80% in my testing.

Economics

Per search: ~$0.005 with Claude Sonnet
Per 1,000 searches: ~$5
DB grows: ~700 unique entries (cache hit ratio improves over time)

After Month 2, ~70% of searches hit cache → AI cost drops while DB value compounds.

What I'd improve

Verification batch job — weekly re-check generated entries against external sources
User flagging — one-click report for wrong entries
Quality tiers — mark "AI-generated" vs "human-verified"

Try it yourself

If you have any niche directory idea (suppliers, restaurants, courses), this pattern unlocks it.

Demo: https://japanbrandfinder.lovable.app/

Twitter: @tokidigitaljp

What would you use the cache-miss enrichment pattern for?

How I auto-enrich a brand database with AI on cache miss (Lovable + Claude API)

mamoru kubokawa — Thu, 14 May 2026 23:47:20 +0000

Most database designs have two ugly options:

Manually seed thousands of rows (impossible for niche data like Japanese wholesale suppliers)
Force users to enter everything (terrible UX, dead-on-arrival)

Last week I shipped a third option in 30 minutes with Lovable: let the database grow itself.

Every search that misses the cache triggers Claude API to generate a real, structured entry — and saves it. The next user gets an instant hit.

Here's the exact pattern.

The pattern in 4 lines

async function search(query) {
  if (await db.has(query)) return db.get(query);
  const entry = await aiGenerate(query);
  await db.save(entry);
  return entry;
}

That's the whole thing. The magic is in what happens to the database over time.

Why this beats alternatives

Seed-only DBs require domain expertise upfront. For my Japan Brand Finder, that meant cold-calling Tsubame-Sanjo metalworkers — months of effort before launching.

User-fed DBs have chicken-and-egg. Empty DB → no value → no users → no entries.

Cache-miss enrichment sidesteps both:

Launch with 20 seed entries (1 hour)
AI fills the long tail as users search
Every miss makes the DB better for the next user
Cost grows linearly with usage (predictable)

The prompt that actually worked

The hard part isn't the pattern. It's getting AI to produce structured, useful entries instead of generic Wikipedia summaries.

What worked for me (Japan Brand Finder context):

You are filling a database row for a Japanese manufacturer.
The user searched: "[QUERY]"

Generate a JSON object:
- name_en: English brand name
- name_jp: Japanese name (kanji or kana)
- category: from this list [...]
- hq_location: city, prefecture
- english_support: "good" | "limited" | "none"
- business_culture_notes: 1-2 sentences

If the brand doesn't exist, return null. Don't invent.

Two key tricks:

JSON schema forces structure (no rambling output)
"Return null if doesn't exist" gives AI permission to refuse

The second one cut hallucination by ~80% in my testing.

Economics

Per search: ~$0.005 with Claude Sonnet
Per 1,000 searches: ~$5
DB grows: ~700 unique entries (cache hit ratio improves over time)

After Month 2, ~70% of searches hit cache → AI cost drops while DB value compounds.

What I'd improve

Verification batch job — weekly re-check generated entries against external sources
User flagging — one-click report for wrong entries
Quality tiers — mark "AI-generated" vs "human-verified"

Try it yourself

If you have any niche directory idea (suppliers, restaurants, courses), this pattern unlocks it.

Demo: https://japanbrandfinder.lovable.app/

Twitter: @tokidigitaljp

What would you use the cache-miss enrichment pattern for?

How I auto-enrich a brand database with AI on cache miss (Lovable + Claude API)

mamoru kubokawa — Wed, 13 May 2026 11:11:36 +0000

Most database designs have two ugly options:

Manually seed thousands of rows (impossible for niche data)
Force users to enter everything (terrible UX)

Last week I shipped a third option in 30 minutes with Lovable:
let the database grow itself.

Every search that misses the cache triggers Claude API to generate
a real, structured entry — and saves it. The next user gets an
instant hit.

Here's the exact pattern.

My first dev.to post got <25 views: 3 things I'm changing

mamoru kubokawa — Mon, 11 May 2026 07:51:20 +0000

3 days ago I published my first dev.to post: "I built a self-growing Japanese brand database in 1 hour with Lovable (0 customers, 0 followers)."

The stats today:

Views: <25
Reactions: 0
Comments: 0
Followers: 0

Here's the honest breakdown of what didn't work, and 3 things I'm changing.

1. Passive doesn't work

I published and waited. No X share, no Reddit, no Indie Hackers (got blocked there anyway as a new account).

The lesson: dev.to alone doesn't distribute itself. It rewards momentum signals — comments, reactions, external traffic. New accounts with no signal stay invisible.

What I'm changing: Today I shared the post on X with a question to indie builders. Tomorrow I'll add genuine comments to 5 #showdev posts I actually find interesting.

2. The title was about me, not them

My old title: "I built a self-growing Japanese brand database in 1 hour with Lovable (0 customers, 0 followers)."

Self-centric. About my journey, my tool, my emptiness.

What works on dev.to: titles framed as the reader's problem or technique.

What I'd write today: "How I auto-enrich a brand database with AI on cache miss (Lovable + Claude API)"

The reader benefit is clearer. The technique is upfront. Use case comes second.

3. I forgot the audience

dev.to is developers. My customers (Amazon sellers) are not.

I wrote about my product like a product person, not a developer. Devs scrolling the feed don't care about Japan sourcing — they care about the pattern I used to build it.

What I'm changing: For my next post, I'll lead with the technical pattern (AI-powered DB enrichment on cache miss) and let the use case come second.

What's next

Comment on 5 #showdev posts genuinely
Engage with any replies on the original post
Write next post with a developer-first angle

Currently still 0 customers, 0 followers — but learning faster.

Demo: https://japanbrandfinder.lovable.app/
Twitter: @tokidigitaljp

What's the most valuable thing you've learned from a post that didn't take off?

I built a self-growing Japanese brand database in 1 hour with Lovable (0 customers, 0 followers)

mamoru kubokawa — Sat, 09 May 2026 07:06:22 +0000

TL;DR: Japanese Amazon seller from Osaka. Yesterday I built Japan Brand Finder in 1 hour with Lovable — a tool helping English-speaking Amazon sellers source from Japan. Currently 0 customers, 0 followers. Building in public. Demo

Why I built this

I'm based in Osaka and I run an Amazon Japan business. For years I've watched English-speaking sellers struggle to source from Japan — language barriers, FAX-only wholesalers, and the silent fear of writing emails that accidentally sound rude.

So I sat down with Lovable and built the thing I wish existed when I started.

What it looks like

The pitch on the landing page: "Search a growing database of Japanese makers — from Tsubame-Sanjo metalworkers to Kyoto matcha houses. Get wholesale contacts, MOQs, English-support level, and culture notes. Then let AI write the polite outreach email for you."

I didn't write that copy. Lovable did. I never mentioned Tsubame-Sanjo (a famous Japanese metalworking region) in my prompt — yet the AI surfaced exactly the kind of specific, credibility-building example that resonates with Amazon sellers who source from Japan.

The database that grows itself

Here's the thing I'm most proud of.

Look at this screenshot. Kyocera, Zojirushi, Tiger Corporation, Daikin, Sharp, Suntory, Nissin Foods, House Foods, IRIS Ohyama. 9 Japanese brands. All marked "AI" — meaning I didn't seed any of them.

When a user searches and the brand isn't in the DB, the AI generates a real entry — name in English and Japanese, category, HQ location, English support level — and saves it to the shared database. The next user who searches that brand gets an instant hit.

Day 1: 20 seed brands
Day 2: 30+ brands and growing
Every user makes the product more valuable for everyone

This is the moat. Not the UI. Not the features. The DB.

How good is the AI-generated outreach email?

This is one click away. Hit "Generate" → AI writes a polite Japanese business email like:

件名：御社製品の卸販売に関するお問い合わせ（海外Amazon販売店より）

池永鉄工株式会社御担当者様

突然のご連絡失礼いたします。

海外にてAmazonストアを運営しております、久保川護と申します...

Three things to notice:

Subject line auto-generated — most AI tools forget this
Native keigo — "突然のご連絡失礼いたします" is the textbook polite opener
Real product knowledge — the email mentions "鉄なべ" (iron pot), Ikenaga's actual product line. The AI pulled this from the brand's business culture metadata

For an English-speaking Amazon seller trying to source from Japan, this single feature replaces a $200/hour translator.

The 1-hour journey

Time	What happened
0:00	Wrote a 200-word spec
0:01	Pasted into Lovable
0:08	First MVP shipped (search, details, favorites, AI email)
0:30	Multi-language search bug fix prompt
0:55	3-mode email feature added with before/after diff
1:00	Free credits ran out at exactly the right moment

What I learned

1. The "Both" option is gold. When Lovable asked how to populate the brand database, the answer was "seed sample brands + AI enrichment on misses." This single decision is what turns the tool into a growing asset.

2. Security scan saved me. Before publishing, Lovable's automated security scan flagged a critical issue (RLS missing — wholesale contacts would have been publicly readable). One click fixed it. Without that scan, I would have shipped a privacy violation.

3. Honest copywriting from AI surprised me. The Tsubame-Sanjo example. The 鉄なべ reference. These weren't in my prompts. The AI just knew what would resonate.

What's next

Beta launch this month — aiming for 10–20 users
Stripe Lifetime Deal ($99) for first 50 buyers
Bug cleanup (some AI entries still have typos)
Better sign-up flow

Currently 0 customers, 0 followers, building entirely in public.

If you're an Amazon seller (or just curious about Japanese sourcing), I'd love your feedback.

🔗 Demo: https://japanbrandfinder.lovable.app/

🐦 Twitter: @tokidigitaljp

🛠️ Built with: Lovable + Supabase + Anthropic Claude API

What feature would you want to see in v2?