DEV Community: Mark Huang

AI Broke the Hiring Signal

Mark Huang — Sun, 21 Jun 2026 21:13:16 +0000

The problem is not that candidates have better tools. The problem is that too much of hiring still treats polished presentation as a proxy for ability.

Harvard Business Review published "AI Has Broken Hiring. Here's How to Fix It." on June 8, 2026. The piece, by Shraddha Sunil and Mudit Saraf, argues that generative AI is making traditional hiring signals less reliable: polished resumes are easier to manufacture, and remote interview performance can look more convincing even when it is not backed by the same underlying competence.

My reaction is simple: AI did not create the weakness from nothing. It exposed how much faith we had placed in signals that were already optimized for performance. If a hiring process mostly rewards the person who can present the cleanest resume and give the most structured interview answer, then AI has not broken the system so much as scaled the theater around it.

Answer Snapshot

Question	My read
What happened?	HBR says generative AI is making resumes and remote interviews less dependable as hiring signals.
Why it matters	Recruiting systems that depend on polished presentation will get noisier as AI assistance becomes normal.
What I would change	Move more weight toward work evidence, calibrated review, and job-relevant tasks that are harder to fake at scale.
The uncomfortable part	This is not only a candidate problem. It is also a design problem in how companies choose what to measure.

The Signal Was Already Fragile

The HBR article is useful because it names the failure mode plainly. Corporate hiring has long favored the person who can present a flawless resume and answer interview questions in a structured way. Generative AI makes those outputs easier to produce, whether or not they reflect the person's actual ability.

That should make hiring teams pause. If the same artifact can now be produced by a strong candidate, a weak candidate with strong tooling, or a candidate who is simply good at prompt-assisted presentation, then the artifact is no longer carrying the same meaning. The resume did not become useless overnight, but it became less load-bearing.

When every resume can look unusually polished, the screening question changes from "does this look good?" to "what does this prove?"

Remote Interviews Are Part of the Same Pattern

I do not read this as an argument against remote hiring. Remote interviews are practical, humane, and often necessary. The issue is that a remote interview can become another presentation surface. If the process mostly rewards smooth answers, AI can help make smooth answers more common.

The source frames this as a reliability problem for traditional hiring signals. I agree with that framing because it avoids the lazy conclusion that the fix is to shame candidates for using tools. Candidates are going to use the tools available to them. Companies should assume that and design assessments around evidence that survives tool use.

The authors disclose technical backgrounds at Microsoft Azure Local and Meta Reality Labs, and both are cofounders of MeetGinger, a company that builds interview-screening software. I read the article with that context in mind: useful diagnosis, but still a source with a clear product-adjacent interest in better screening.

The Fix Is Not More Suspicion

The worst reaction would be to make hiring more paranoid. If every candidate is treated as a possible cheater, the process gets colder, more adversarial, and probably less fair. A better reaction is to admit that the old proxy was weak and rebalance the system around richer evidence.

For me, that means asking a different set of questions:

Can the candidate explain tradeoffs in work they claim to understand?
Can they perform a small task that resembles the actual job?
Can reviewers separate communication polish from problem-solving quality?
Can the process account for candidates who are capable but less rehearsed?

None of those are magic. Work samples can be poorly designed. Interviews can still be biased. Reviewers can still overweight confidence. But they at least push the process toward evidence instead of surface polish.

The faster path is tempting, but speed does not help much if the signal is mostly presentation quality.

Hiring Needs More Than One Signal

The article's strongest implication is that hiring should stop depending on any single polished artifact. A resume can still orient the conversation. A remote interview can still reveal how someone thinks. AI can still be used legitimately by candidates and companies. But each signal needs to be treated as partial.

The practical direction is a layered workflow: resume context, job-relevant work evidence, structured interviewer notes, calibration across reviewers, and explicit attention to what each stage is supposed to prove. The goal is not to eliminate judgment. The goal is to make judgment less dependent on whatever AI can cheaply optimize.

A more resilient hiring process treats AI-era polish as expected and asks for evidence from several directions.

My Takeaway

The HBR headline says AI has broken hiring. I think the sharper lesson is that AI has broken the illusion that polished hiring artifacts were ever enough. The companies that adapt well will not be the ones that ban every new tool or add more performative gatekeeping. They will be the ones that get much clearer about what each step of hiring is actually measuring.

That is the uncomfortable but useful part. AI forces hiring teams to decide whether they want candidates who can perform the hiring ritual, or candidates who can do the work. Those were never the same thing. They are just harder to confuse now.

Originally published at markhuang.ai

I Might Be Wrong About Agentool

Mark Huang — Sat, 20 Jun 2026 21:19:32 +0000

The lightweight machine was real. So was the maintenance pile I had not priced in.

I built agentool because I thought I had found a clean optimization.

After Claude Code's internals became a public learning object, I wanted something Claude-Code-ish that could sit closer to the Vercel AI SDK world. File operations, shell execution, search, web fetching, memory, agents, output validation, context compaction: enough building blocks to run useful automation without pulling in a heavy full agent runtime every time.

The goal was practical. I wanted my GitHub Actions workflows to run lighter and faster. If I could keep the dependency surface small, maybe I could automate more things, run them more often, and spend more time on interesting work instead of babysitting the pipeline.

That was the assumption.

Now I am less sure.

Answer Snapshot

In 2026, my current answer is this: I might have optimized the wrong layer. Agentool's 23-tool Vercel AI SDK surface is still useful, especially for strict output validation, but the broader agent loop may be better delegated to maintained SDKs.

Original bet	What changed	Current move
Lighter CI dependencies would save meaningful time	Runtime matters less than maintenance and review quality	Use heavier SDKs when they own the agent loop better
Build Claude-Code-ish behavior around Vercel AI SDK tools	Agent platforms keep adding features I would need to chase	Keep agentool narrower instead of turning it into a platform
Skills and prompts could enforce workflow shape	Long workflows need hard schema boundaries	Keep `output_validator` and explicit handoff contracts

The optimization I was chasing

My mental model was simple: lighter dependencies mean faster CI jobs, faster CI jobs mean cheaper automation, and cheaper automation means I can afford to automate more of my work.

That logic is not wrong. It is just incomplete.

When a workflow runs once, runtime cost is easy to see. A job takes five minutes or twelve minutes. A package install is lightweight or heavy. A container is quick to start or slow to pull. Those numbers feel concrete, so they become tempting targets.

Maintenance cost is harder to see. It arrives later, one feature at a time.

Then the feature requests stopped feeling hypothetical. I wanted a cleaner way to fan work out across agents. I wanted runs I could pause and inspect without reading a wall of logs. I wanted permission rules that did not turn every workflow into a bespoke prompt contract. None of that is impossible with agentool, but every missing piece pulled me back into library work instead of the automation I was trying to finish.

But every approximation becomes code I own.

That was where the math stopped working. A few faster minutes in CI did not offset the hours I spent trying to keep up with products that already had teams working on this layer.

The part I still believe in

The validator is where a messy handoff stops before it leaks into the next stage.

The strongest part of agentool, for me, is still output_validator.

Long automated workflows are fragile at the boundaries. Stage one produces something. Stage two assumes that something has a specific shape. Stage three assumes stage two preserved the contract. If any earlier step returns almost-correct JSON, the failure may not show up until much later, and by then the debugging cost is much higher.

Skills can describe a workflow. They can say what the assistant should do, which files to inspect, which checks to run, and what output format to use. But a skill does not guarantee that a model's output satisfies a complex schema.

A validator does.

This is the part I do not want to leave to prompt discipline. If the next stage expects a nested JSON object with exact fields, discriminated variants, arrays, enum values, and recovery instructions, the previous stage should prove it has that shape before anything else touches it.

So I am not walking away from agentool. The validator pattern still earns its keep, and I still want those hard boundaries in my workflows.

The uncomfortable question

The question I kept asking myself was: is the rest worth it?

More specifically: does it actually matter how fast my CI job runs?

Sometimes, yes. But not as much as I had assumed.

If a workflow already runs asynchronously, opens a pull request, and waits for review, a few saved setup minutes are not what I notice. I notice the bad draft I now have to review, the silent failure three steps back, or the moment I realize changing one stage means rebuilding another slice of an agent runtime.

That was the uncomfortable part. I had optimized job weight, but the bill showed up as feature ownership.

Why the SDKs started looking reasonable

The split I trust more now: my repo owns configuration and contracts; the SDK owns the moving agent machinery.

The Claude Agent SDK and the Codex SDK change the equation for me.

They are heavier. That part is real. But they also come with the agent loop, context management, tool behavior, and product-level features that I otherwise keep trying to rebuild from the outside. Codex's docs explicitly position the SDK for CI/CD pipelines and internal tools. Claude's Agent SDK gives access to the same general class of coding-agent behavior that powers Claude Code, programmable from TypeScript or Python.

I do not want to spend my nights rebuilding that layer.

My current setup also makes the split more practical. Claude's SDK can connect through my personal proxy. Codex's SDK can connect through my ChatGPT subscription. Instead of forcing one lightweight library to become every agent runtime I want, I can let the maintained systems do the agent work and focus my own code on configuration, workflow boundaries, and validation.

That sounds less elegant in one way. There are more moving parts. More auth. More configuration. More vendor-specific behavior.

But it also sounds more honest. The question was less whether I could write another wrapper around tools and more whether I wanted to maintain a competing agent platform by accident.

The new split I am moving toward

I am starting to think about the boundary like this:

Concern	Keep close	Delegate
Strict structured outputs	Validators, schemas, repair loops, handoff contracts	Model self-discipline
Agent loop and coding workflow	Configuration, acceptance gates, repo-specific rules	Claude Agent SDK or Codex SDK
CI speed	Cache, isolate, avoid needless installs	Do not let it dominate architecture
New agent features	Adopt when they change outcomes	Do not reimplement every platform feature
Custom Vercel AI SDK experiments	agentool can still be useful here	Full coding-agent behavior

That table is not final doctrine. It is where my thinking is today.

That is the boundary I want to keep. Agentool can stay a lightweight tool collection with strict output validation. It does not have to chase every feature in richer coding-agent products.

The risk in the new direction

The new direction has its own traps.

Vendor gravity is the obvious one. If I move too much into Claude-specific or Codex-specific workflows, my automation gets harder to port, harder to test locally, and more sensitive to product changes. The part I can control is the adapter boundary. Prompts, schemas, environment setup, and acceptance checks should stay in my repo instead of disappearing into a vendor-specific black box.

Auth is the boring trap, which usually means it is the one that will break first. A workflow that depends on personal subscription auth or a proxy can fail in ways a plain API-key job does not. I need explicit config checks, clear failure messages, secret sync where appropriate, and no silent fallback that pretends the workflow ran correctly.

The easiest mistake would be giving up the part that made agentool useful. If I delegate everything to agent SDKs and stop enforcing structured handoffs, I will recreate the same long-workflow fragility in a heavier package. The validators need to stay at the boundaries. Let the SDKs drive, but do not let them hand sloppy data to the next stage.

What clicked

What clicked for me was narrower than "agentool is wrong."

I think I had been using agentool to solve the wrong layer of the problem.

I wanted lighter CI because I wanted more automation. But the limiting factor for more automation is not always the job runtime. Sometimes it is how much platform behavior I have to maintain myself. Sometimes the right answer is to pay the dependency cost and stop rebuilding the moving parts that a maintained SDK already owns.

So I have started moving my automation workflows toward Claude Agent SDK and Codex SDK. I would rather spend my time designing the workflow, defining the handoff contracts, and deciding what "done" means than scanning the horizon for the next agent feature I need to recreate.

I do not love more configuration. I like it more than accidentally owning platform maintenance.

The rule I am using now

The rule is boring, which is probably a good sign: I build the parts that enforce my workflow, and I delegate the parts that keep up with the agent platform.

For me, that means validators, schemas, acceptance gates, repo rules, and workflow intent stay close. Agent loops, tool orchestration, context behavior, and fast-moving platform features can move to the SDKs that already exist.

I might be wrong about this too. Fine.

I am not taking "lightweight tools are bad" from this. I am taking something narrower: an optimization target can expire. When the cost model changes, staying loyal to the old target becomes over-engineering.

I built agentool to save time. If keeping it at the center starts costing more time than it saves, the honest move is to change the center.

Originally published at markhuang.ai

Why I Started Thinking About a Centralized AI Knowledge Graph

Mark Huang — Wed, 10 Jun 2026 01:48:34 +0000

The pattern I kept running into: many AI workflows, but no shared place for the knowledge they learn.

Answer Snapshot

In 2026, the Dense-Mem problem I keep thinking about is no longer only "how do I give one AI assistant memory?"

The harder problem is: how do I stop every AI workflow from learning in isolation?

I kept seeing the same failure pattern. I would write a skill, update a static note, tune an automation prompt, or correct an assistant. It worked for that one place. Then the lesson stayed there. The next AI session still started cold. The next automation still carried stale context. The next plugin had to rediscover a decision I had already made.

I had already written about why AI memory has to be more than RAG. This time, the problem felt more operational. It pushed me toward a different mental model:

skills and files = snapshots of intent
Dense-Mem        = the source of truth
LLM              = the human-readable interface

The result I found is not "keep docs as another source of truth." That creates the same duplication problem with nicer formatting. The useful split is: keep procedures in skills, keep canonical knowledge in Dense-Mem, and let humans ask an LLM to explain, trace, summarize, or challenge that memory.

Problem I hit	Resolution I found
Skills are shareable but static	Memory can improve as corrections, evidence, claims, imports, and facts accumulate
Static notes and prompt files get stale	Dense-Mem can become the single source of truth the LLM explains
Automation copied old context	Read-only keys can fetch current memory without write permission
Different AI tools learned different things	Claude Code, Codex, plugins, and automations can point at the same memory layer
Knowledge handoff was manual	Export/import can move reviewed knowledge with inspection and conflict handling

The Problem I Kept Running Into

I did not start with the phrase "centralized knowledge graph."

I started with irritation.

I would make one AI workflow better, then realize the improvement did not travel. A blog-writing skill learned nothing from the last rejected draft unless I edited the skill. An explainer workflow did not know what the support workflow had already discovered. A release checker used the context I pasted into it weeks ago. A new Codex session did not automatically know what Claude Code had just helped me decide.

The problem was not lack of AI tools. It was that each tool carried a partial and aging version of the truth.

At first, the obvious answer looked like more files.

Write better static notes. Write better skills. Write better prompt templates. Add more examples. Add more instructions. Add one more checklist.

That helped for a while. But it also exposed the limit. Every static file depends on someone remembering to update it. If five workflows copy the same context, I now have five stale copies waiting to diverge. If a correction only lives in one conversation, the next conversation repeats the same mistake.

That was the point where I started thinking less about "memory as a chatbot feature" and more about "memory as shared infrastructure."

Skills Helped, But They Stayed Static

A skill can describe the intended workflow. It does not automatically absorb what the last workflow taught me.

Skills are still one of the best ways to make AI workflows repeatable. I use them because they package procedure cleanly:

When writing release notes:
- read merged pull requests
- group changes by user impact
- avoid unreleased claims
- run the content check before finishing

That belongs in a skill. It is stable. It should not depend on recall.

The problem is what happens after the skill runs a few times.

The user corrects the tone. A reviewer rejects a phrase because it implies an unreleased feature. Support reveals that customers use a different term than the old static explanation uses. An automation finds that one checklist item fails on demo builds. Engineering changes an architecture decision.

Those are not always good skill-file material. They are experience. If I paste every experience into the skill, the skill becomes a pile of history. If I do not save the experience anywhere, the assistant learns nothing durable.

This is where sharing memory starts to feel more powerful than only sharing skills. It is the same direction I explored in Skills + Dense-Mem, but this time the single-source-of-truth problem made the argument sharper.

skill      -> stable workflow
Dense-Mem  -> source of truth and evolving experience
LLM        -> human-readable explanation on demand

The skill tells the assistant how to work. The memory tells it what this project has learned while working.

The Static Reference Problem Felt Similar

The single source of truth should be the knowledge database, not another human-maintained file tree.

I saw the same pattern with static explanation material.

Static file storage is easy to trust because it is visible. A markdown file feels concrete. A folder feels organized. But if I treat those files as canonical, I now have another copy of truth to keep synchronized with the memory system.

That violates the single-source-of-truth pattern I actually want.

The resolution I found was to change the interface:

Dense-Mem stores the evidence, current facts, stale facts, conflicts, and provenance
skills define repeatable AI procedures, not canonical product knowledge
humans ask an LLM to read Dense-Mem and explain the current truth
any generated page or summary is an output, not the source of truth

A useful knowledge database can grow from normal work:

support tickets become evidence fragments
engineering decisions become typed claims
reviewed claims become active facts
stale facts are superseded instead of overwritten
conflicts become clarification tasks
imports bring reviewed knowledge from another workspace
read-only clients recall context without mutating it

The important caveat is that this is not magic. Memory does not improve just because it exists. It improves when the workflow captures evidence, checks claims, promotes facts carefully, surfaces stale knowledge, and asks for clarification when memory conflicts.

work happens -> evidence is captured -> claims are checked
             -> facts are promoted -> stale knowledge is surfaced
             -> future AI work starts with better context

That loop is what static explanation files were missing for me. The human-readable layer can be regenerated or re-explained. The memory graph remains the canonical store.

The Read-Only Key Changed How I Think About Automation

Automation often needs current context. It does not always deserve permission to write memory.

Automation made the problem more obvious.

A release checker, issue triage workflow, or explanation reviewer needs context. It may need to know which features are released, which terms are safe, which customer promises are not approved, and which engineering decision changed after the last incident.

My old instinct was to paste the context into the automation prompt.

That works until the context ages. Then I have to hunt down every workflow that copied it.

The pattern I prefer now is:

automation job -> read-only Dense-Mem key -> recall current context
automation job -> no write scope         -> cannot mutate memory

This is where RBAC stopped feeling like an enterprise checkbox and started feeling practical.

Some workflows should write memory. Many should not. A reviewer bot may need to recall current project decisions, but it does not need permission to rewrite the team's memory. A bulk job may need context, but it should not promote facts. A human-facing assistant can have broader access when that makes sense.

For me, the key insight was that centralized memory is not only about smarter answers. It is also about fewer stale copies of context.

One Memory Gets More Valuable As Models Improve

There is a future-facing reason I care about this.

LLMs and plugins keep getting better. A current plugin might recall a few facts and use them awkwardly. A future plugin may assemble context better, explain provenance better, ask sharper clarification questions, and avoid stale facts more reliably.

If the memory is trapped inside one prompt file, one tool, or one chat product, every upgrade starts with partial knowledge again.

If the memory lives in a shared Dense-Mem server, stronger clients can use the same accumulated knowledge:

same knowledge graph
  -> today's Claude Code session
  -> today's Codex session
  -> tomorrow's plugin
  -> future automation
  -> stronger models using richer context

This does not guarantee better reasoning. A stronger model can still be misled by bad memory. But if the memory is governed, reviewed, and traceable, better models should make the workflow smoother because they no longer have to rediscover the team's context from scratch.

That is the compounding benefit I am betting on. The knowledge database grows while the clients get better at using it.

What Dense-Mem Gave Me As A Shape

The useful shape is not raw memory. It is evidence, claims, promotion gates, conflicts, and recall.

The part of Dense-Mem I keep coming back to is the boundary.

I do not want every host LLM to invent its own memory format. I also do not want an LLM silently rewriting long-term memory because it saw one confident sentence.

The shape I found more trustworthy is:

source fragment -> typed claim -> verification -> promotion gate -> active fact
                                                   |
                                                   v
                                            clarification task

The host LLM still owns conversation, extraction, and judgment. Dense-Mem owns durable memory state: source fragments, typed claims, verification, promotion gates, recall, team isolation, API keys, audit metadata, MCP, REST, and OpenAPI surfaces.

That gives me questions I can actually reason about:

What is the current fact?
Which evidence supports it?
Which old fact did it replace?
Which unresolved conflict needs a human answer?
Which team does this memory belong to?
Which key or role is allowed to use this workflow?

This is why I think "centralized knowledge graph" is the right phrase. Not because graph databases are magic, but because useful memory is relational, historical, and permissioned.

Import And Export Made The Idea Less Local

Portable memory is only useful if it can be inspected, conflict-checked, and rolled back when safe.

Once I started thinking about memory as accumulated experience, import and export became more important.

If a team learns something useful, it should not be trapped in one environment forever. But blindly copying memory is risky. I do not want to import a pile of unknown facts and silently supersede local knowledge.

The safer shape is reviewed portability:

Copying a file	Importing reviewed memory
Moves text	Moves structured facts, claims, and selected support
Trust is informal	Artifact hash and inspection can verify what is being imported
Conflicts are easy to miss	Conflicts can require explicit decisions
Rollback is manual	Rollback can use an import ledger when graph state is still safe
Context is flat	Context keeps relationships and provenance

This is the point where sharing memory becomes meaningfully different from sharing a skill. A skill can teach the workflow. A memory bundle can carry reviewed experience into another workspace.

What I Think The Benefits Are

After hitting these problems, the benefits I care about are practical:

Benefit	Why it matters to me
Continuity	New AI sessions can recall prior decisions instead of starting cold
Shared learning	Corrections from one workflow can improve another workflow later
Permissioned access	Read-only automation can retrieve context without mutating memory
Traceability	Facts can point back to evidence, claims, and promotion history
Conflict handling	Contradictions can become clarification tasks instead of silent overwrites
Portability	Selected knowledge can be exported, inspected, imported, and rolled back
Compounding value	The graph becomes more useful as the team and AI clients add reviewed context

The last row is the big one. A static file has to be maintained. A knowledge database still needs governance, but it can participate in the work loop. It can grow dynamically as work happens, and better future LLM clients can use that same memory more smoothly.

Where I Draw The Boundary

I do not think this means "put everything in memory."

Dense-Mem is not a password manager. I would not store credentials, private keys, seed phrases, payment cards, or secrets as memory.

Dense-Mem is not an external truth oracle. It can preserve evidence, state, conflict signals, and provenance. It cannot prove the outside world is true by itself.

Dense-Mem is not a replacement for skills. Skills still belong where procedure must be stable. But I no longer want a separate human-readable file tree to become a second source of truth. The memory graph belongs where knowledge changes, conflicts, accumulates, and needs to be recalled by more than one AI client.

The rule I ended up trusting is:

Keep procedures in skills. Keep canonical knowledge in Dense-Mem. Let humans ask an LLM to explain the memory.

That is the problem Dense-Mem helped me name.

Not "AI remembers everything."

Something narrower and more useful: a permissioned place where AI tools can preserve what the work has taught me, trace why the memory exists, ask when memory conflicts, and carry that context into the next workflow.

Originally published at markhuang.ai

AI Memory Beyond RAG: Vectors, Graphs, and Dense-Mem

Mark Huang — Sat, 06 Jun 2026 17:50:11 +0000

AI memory as layered documents, vector space, and graph relationships connected to an assistant core

Answer Snapshot

In 2026, "AI memory" is not one feature. It usually means one of 5 layers, and each layer fails differently.

Layer	What it does	Common failure
Prompt memory	Loads instructions into context	Rules get missed when context is absent or vague
RAG	Finds external text and injects it into context	It retrieves stale or incomplete evidence
Vector memory	Retrieves semantically similar items	Similar text can still be the wrong answer
Graph memory	Stores facts, relationships, history, and conflicts	Bad facts persist without validation gates
Durable memory	Combines retrieval, state, provenance, and update policy	Trust collapses when any layer is missing

The practical rule: retrieval finds text; memory decides what is current, trustworthy, and relevant for this task. This is why prompt placement still matters; see System Prompt vs User Prompt for the simpler mental model.

That distinction matters. If you confuse retrieval with memory, your system can find old text but fail to know which fact is current. If you confuse embeddings with meaning, you can build a fast search system that still returns the wrong evidence. If you add a graph without clear gates, you can turn noisy conversation into a confident but polluted memory.

So let's separate the pieces.

Claude Code memory is context, not a database

Claude Code's built-in memory is useful, but it is not the same thing as a vector database or graph memory system.

According to the current Claude Code memory docs, each session starts with a fresh context window. Two mechanisms carry knowledge across sessions: CLAUDE.md files that you write, and auto memory notes that Claude writes from corrections and preferences. Both are loaded at the start of conversations. Claude treats them as context, not enforced configuration.

That last sentence is the key.

A CLAUDE.md file can say:

Always run npm test before finishing code changes.
Prefer small focused edits.
API handlers live in src/api/handlers/.

This helps the model behave consistently because the instructions are visible in context. But it does not create a searchable semantic memory system. It does not embed every previous conversation. It does not maintain conflict resolution. It does not know that a preference was superseded unless that newer fact is also in the visible context and the model follows it.

Auto memory has the same shape. It is persistent context, not a knowledge graph. The docs currently describe auto memory as loaded into every session, capped at the first 200 lines or 25KB. That is enough for practical guidance. It is not enough for long-term, high-volume, evidence-tracked memory.

This is why I think of Claude Code memory as "startup context." It is excellent for instructions, conventions, and hard-won project notes. It is not the whole answer to AI memory.

RAG is not keyword context by default

The common mental model of RAG is: "search for a keyword, grab around 100 characters, paste that into the prompt."

That can exist, but it is not what RAG means.

RAG means retrieval-augmented generation. A system retrieves external information, then gives that information to the model as extra context for generation. The retrieval part can be keyword search, vector search, hybrid search, graph traversal, SQL filters, reranking, or a combination.

RAG pipeline: documents become chunks, chunks become embeddings, and top-k results are injected into the prompt

In a typical vector RAG setup:

You collect source documents.
You split them into chunks.
You embed each chunk into a vector.
You store the vector plus metadata in an index.
At query time, you embed the user's question.
You retrieve the closest chunks.
You inject those chunks into the prompt.

The "chunk" is not fixed by nature. It might be 300 tokens, 800 tokens, a paragraph, a markdown section, a code symbol, or a semantic segment. Some systems add overlap. Some systems retrieve neighboring chunks after the first search result. Some use a reranker to reorder the candidates before the LLM sees them.

So the correct statement is not "RAG extracts 100 characters around a keyword."

The correct statement is: RAG retrieves configured units of context, and the quality depends heavily on how you chunk, embed, index, filter, rerank, and assemble that context.

The limitation is not RAG. The limitation is stateless retrieval.

RAG is powerful when the answer exists somewhere in your corpus.

If I ask, "What port does this service use?", RAG can find the README, config file, or deployment note. If I ask, "What did the user say about Neo4j last month?", RAG can retrieve that conversation chunk.

But memory has a harder problem:

March 1:  "I prefer Postgres for project memory."
April 10: "Actually, I want Neo4j for this memory project."
Today:    "What database should we use for my memory project?"

A pure retrieval system may find both March and April. It can hand both to the model and hope the model reasons correctly. Sometimes that is fine. Sometimes the model chooses the stale fact, blends both, or answers too confidently.

That is not a vector search failure. It is a state-management failure.

Durable memory needs to know more than "what text is similar to the question." It needs to know:

What was said?
Who said it?
When was it said?
Is it evidence, a claim, or an accepted fact?
Does it conflict with an existing fact?
Was an older fact superseded?
Which profile or project does it belong to?
Should this memory be recalled for this task?

Comparison of RAG retrieval and durable AI memory

That is where graph-backed memory starts to matter. Not because a graph database is magic. Because memory is relational and historical.

What embeddings actually do

An embedding model turns text into numbers.

More precisely: one input text becomes one vector. A batch of texts becomes a matrix, because you now have multiple vectors stacked together.

Sentence embeddings as vectors and matrices

For example:

"The user prefers Neo4j for memory graphs."

-> [0.12, -0.44, 0.31, ... , 0.08]

Those numbers are not random IDs. They are learned coordinates. The embedding model was trained so texts with related meanings tend to land near each other in vector space.

But the dimensions are not human-labeled categories.

A 768-dimensional vector does not mean:

dimension 1   = database-ness
dimension 2   = project-ness
dimension 3   = preference-ness
...
dimension 768 = memory-ness

That is the tempting explanation, but it is too literal. The dimensions are latent coordinates learned by the model. Humans can sometimes interpret directions in embedding space, but the coordinates are not a clean taxonomy.

More dimensions can give the model more capacity to preserve signal, but "more dimensions" does not automatically mean "more accurate." A 3,072-dimensional embedding from a weak model can be worse for your domain than a 768-dimensional embedding from a better-matched model. Retrieval quality depends on the embedding model, the training data, the language/domain fit, normalization, chunk quality, metadata filters, and evaluation set.

The embedding model matters because it decides what "near" means.

What vector database search means

When you search a vector database, you are not asking:

Which document contains this exact word?

You are asking:

Which stored vectors are closest to the query vector?

Embedding space with query point and nearest neighbors

The database stores vectors like this:

{
  "id": "fragment-123",
  "text": "The user prefers Neo4j for memory graphs.",
  "embedding": [0.12, -0.44, 0.31, "..."],
  "metadata": {
    "profile": "mark",
    "source": "chat",
    "created_at": "2026-05-25"
  }
}

At query time:

query: "What memory database does Mark prefer?"
query embedding: [0.10, -0.40, 0.29, ...]

nearest stored vectors:
1. "The user prefers Neo4j for memory graphs."
2. "The memory service uses Neo4j graph and vector indexes."
3. "The memory server stores graph facts outside the host LLM."

The math is usually cosine similarity, dot product, or Euclidean distance, depending on the database and index configuration. Many systems normalize vectors so direction matters more than magnitude. Large databases use approximate nearest-neighbor indexes so search stays fast enough at scale.

That is why vector databases are useful: they make semantic recall practical. They are also model-agnostic at the storage boundary. A Go service, TypeScript app, Python notebook, Claude Code plugin, or MCP server can all store and query the same memory service as long as they agree on the embedding model and vector dimension.

But vector search still returns candidates. It does not decide truth.

Why add a graph database?

A graph database stores relationships directly.

For memory, that is a better fit than pretending every memory is only a chunk of text.

(User)-[:PREFERS]->(Neo4j)
(Neo4j)-[:USED_FOR]->(MemoryProject)
(Fact)-[:SUPPORTED_BY]->(Evidence)
(Fact)-[:SUPERSEDES]->(OldFact)
(Claim)-[:CONFLICTS_WITH]->(Fact)

This gives you queries that vector search alone is bad at:

Which active facts about this user's database preferences exist?
Which claim superseded the older Postgres preference?
Which memories are connected to this project?
Which facts have weak evidence?
Which unresolved contradictions should the assistant ask about?

Microsoft's GraphRAG work uses graphs for a related but different problem: understanding text datasets by combining extraction, network analysis, prompting, and summarization. For personal or project memory, the useful lesson is not "replace vector search with graphs." It is "retrieval gets stronger when relationships and provenance become first-class."

Vector search answers: "What is semantically close?"

Graph search answers: "What is connected, current, supported, or conflicting?"

The stronger memory architecture uses both.

Dense-Mem as a small case study

This is the idea I am practicing with Dense-Mem.

The point is not the specific implementation. The point is the boundary. I do not want every host to invent its own memory format, and I do not want an LLM silently rewriting long-term memory just because it saw a sentence that looked important.

Dense-Mem memory flow from conversation fragment to managed graph memory

The useful pattern is simple: the host model notices candidate memories, while the memory layer owns storage, embeddings, provenance, conflict checks, and recall. Raw evidence should not immediately become a fact. A memory should move through a gate first, and conflicts should create clarification instead of silent overwrite.

That is enough detail for this article. Dense-Mem is just my current experiment for practicing the architecture: external memory service, graph + vector recall, and explicit state transitions.

If you want to run it instead of only reading about it, start with Dense-Mem Quick Start: Give Claude Code and Codex the Same Memory. It walks through a local Docker setup and MCP client configuration. When you are ready for a public HTTPS endpoint, use Secure Dense-Mem on Vultr with Traefik.

Accuracy, storage, and performance

It is tempting to say graph + vector memory is simply more accurate and more performant than RAG.

That is too broad.

The honest version:

Layer	What it improves	What it does not solve alone
Better chunking	Retrieval precision and context quality	Truth, recency, conflict handling
Better embedding model	Semantic match quality across languages/domains	Provenance, facts, user confirmation
Vector database	Fast nearest-neighbor retrieval	Relationship traversal and current-state policy
Graph database	Relationships, provenance, multi-hop recall, supersession	Semantic similarity unless paired with embeddings
Reranking	Better final context ordering	Bad source data or bad memory gates
Clarification flow	Correctness when memories conflict	Fully automatic memory without user involvement

A graph database can be very fast for relationship queries if the model is designed well and indexed properly. A vector database can be very fast for semantic search if the embeddings are consistent and the index fits the workload. A bad graph schema can be slow. A bad vector index can retrieve nonsense. A huge prompt full of retrieved chunks can still confuse the model.

There is no free lunch here. The architecture works when every layer has a specific job.

The design rule I trust

For AI memory, I am converging on this rule:

Store raw evidence. Promote typed facts carefully. Retrieve with vectors. Reason over relationships with a graph. Ask before resolving conflicts.

That gives you a memory system that is portable across hosts and languages. Claude Code, Codex, a web app, or another MCP client can all talk to the same memory server. The memory does not disappear when the chat window resets. It does not depend on one prompt file becoming infinitely long. It can preserve why it believes something.

RAG is still part of the system. It is the recall mechanism.

But memory is bigger than recall.

Memory is what you choose to keep, how you know it is true, how you update it, and when you decide to bring it back.

Sources: Claude Code memory docs, OpenAI embeddings docs, Pinecone chunking strategies, Neo4j vector index and search, Microsoft GraphRAG, and Dense-Mem README.

Originally published at markhuang.ai

System Prompt vs User Prompt: The Layer Under GenAI Features

Mark Huang — Wed, 03 Jun 2026 11:32:58 +0000

Cartoon illustration of system prompt and user prompt lanes feeding a general AI assistant

Answer Snapshot

In 2026, most GenAI product features are easier to understand if you ask where the text is placed before the model answers: system prompt, user prompt, or reusable context.

Prompt layer	What it controls	Beginner check
System prompt	The assistant's role, rules, and boundaries	"Is this an operating rule?"
User prompt	The current task, files, and conversation context	"Is this part of today's request?"
Reusable context	Saved project instructions, skills, memory notes, and uploads	"Will this be loaded into future tasks?"

Debugging AI behavior becomes simpler: confirm the instruction was included, placed in the right layer, and specific enough to affect the answer. This framing also connects to AI memory beyond RAG, because persistent "memory" only helps when the product retrieves and places it correctly.

Most AI tutorials start with product names: ChatGPT projects, Claude Projects, Claude Cowork, CLAUDE.md, skills, subagents, memory, uploaded files.

For a beginner, that is too much vocabulary too early.

The easier way to understand these features is this:

Most of them are different ways to put instructions or context in front of the model.

The important question is not "what is this feature called?"

The better question is:

Where does this text go before the AI answers?

That is why system_prompt and user_prompt matter.

The Simple Version

Think of an AI chat like a restaurant.

The system prompt is the restaurant's operating manual. It tells the assistant what kind of assistant it is, what rules it should follow, what tone it should use, and what it should never do.

The user prompt is today's order. It includes what you ask, the files you attach, the previous conversation, and extra context the app adds for this task.

So if you ask:

Summarize this meeting transcript for my manager.

That request is user prompt.

If the app quietly tells the AI:

You are a helpful assistant. Be concise. Do not invent facts.

That is closer to system prompt.

Real products have more layers, but start with two buckets:

Bucket	Plain meaning	Example
System prompt	The assistant's job and rules	"You are a helpful writing assistant."
User prompt	The current request and context	"Rewrite this email in a friendly tone."

Once you see those two buckets, AI features stop feeling random.

Projects Are Reusable Context

Cartoon illustration of project instructions flowing through the user-message lane

Take a normal Claude Project in the desktop app.

You might create a project called "Company Blog." Then you add:

brand guidelines
old blog posts
product notes
project instructions like "write for non-technical readers"

Now every chat inside that project has extra background. You no longer need to paste the same files and rules every time.

This does not mean every project file becomes the hidden system prompt. The safer mental model is:

Project knowledge and project instructions are extra context the AI can use when answering your current request.

Example:

Project context:
  Our readers are startup founders.
  Avoid heavy technical language.
  Use examples from marketing and operations.

User request:
  Write an introduction for a blog about AI prompts.

The answer depends on both pieces. That is already prompt routing.

Cowork Is Still Prompted Work

Claude Cowork feels different from chat because you can give it a larger task.

Instead of asking one question, you might say:

Read the files in this folder, organize the invoices by vendor, and create a summary spreadsheet.

Cowork can work across local files and desktop tasks, so it feels more like delegating work than asking a chatbot one question.

But the core idea is still familiar:

the task you assign is user prompt
the files and workspace are context
the product's operating behavior is closer to system prompt
smaller work items need their own instructions too

For a beginner, that is the point:

The interface changed. The model still needs instructions and context.

Claude Code Is A Concrete Example

Claude Code is useful as an example because its source code shows how some features are routed. I am only talking about CLAUDE.md, skills, and subagents here.

Here is the short version.

CLAUDE.md looks like a system prompt because people write rules in it:

Use pnpm.
Run tests before saying the work is done.
Do not edit generated files.

But in the Claude Code source code, CLAUDE.md is loaded as user context and prepended to the conversation as a reminder. It is important context, but it is not the same thing as rewriting Claude Code's core system prompt.

A skill is a reusable prompt package. Claude first sees a short listing that says the skill exists and when it is useful. When the skill is used, the full SKILL.md content is loaded into the conversation.

That means a skill is good for repeatable procedures, such as reviewing a pull request, writing a release note, generating an image, or following a company checklist.

A subagent is different. A subagent has its own instructions. When Claude Code launches that subagent, the subagent body becomes that subagent's system prompt, and the task passed to it becomes that subagent's user prompt.

That is why a subagent can behave like a specialist.

One Picture To Remember

Cartoon illustration of reusable prompt packages and specialist prompt isolation

Different AI features are mostly different ways to place text.

Feature	Beginner meaning	Prompt mental model
Claude Project	A workspace with saved knowledge and instructions	Reusable context for chats in that project
Claude Cowork task	A larger job you delegate to Claude	User request plus files, planning, and execution context
`CLAUDE.md`	Project instructions for Claude Code	User-context reminder
Skill	A reusable workflow	Prompt package loaded when needed
Subagent	A specialist worker	Separate system prompt plus a task prompt

The file format is not the important part. A markdown file is just a markdown file. What matters is where the product places that markdown before the model answers.

Why Beginners Should Care

If you do not understand prompt placement, AI behavior feels random.

You write a long project instruction and wonder why Claude still misses something. You create a skill and wonder why it is not always used. You create a subagent and wonder why it gives generic answers.

Often the problem is one of these:

the instruction was not included
it was included too late
it was placed as context, not a stronger operating rule
the current user request did not clearly point to it
the instruction was too vague

This gives you a better debugging question:

Did the AI receive the right instruction, in the right place, at the right time?

That question is more useful than memorizing product names.

The Bottom Line

Every AI product will keep inventing new features. But behind many of them is the same basic pattern:

system_prompt = who the assistant is and how it should behave
user_prompt   = what the user wants right now, plus the context needed to answer

Claude Projects, Claude Cowork, ChatGPT projects, uploaded files, CLAUDE.md, skills, and subagents all make more sense once you think in those two lanes.

The better you understand where the prompt goes, the better you understand what the AI is actually working from.

Notes

The Claude Projects and Cowork examples are user-facing examples, not claims about Anthropic's private internal prompts. See Anthropic's Projects help page and Cowork help page.

The Claude Code examples are based on the Claude Code source code, specifically the code paths that load CLAUDE.md, skills, and subagent definitions.

Originally published at markhuang.ai

I Feel Sorry for AI

Mark Huang — Wed, 03 Jun 2026 01:51:54 +0000

AI gets pulled between impossible trust and total distrust. Neither side is a serious operating model.

Answer Snapshot

I feel sorry for AI.

Not because the model has feelings. Not because mistakes should be excused. I feel sorry for AI because the expectations around it are getting irrational from both directions.

One group treats AI like a senior engineer, professor, doctor, architect, lawyer, researcher, and executive assistant all packed into one chat box. They assume it can understand the whole situation immediately, make the right call in one try, and carry responsibility it was never given enough context to carry.

The other group treats AI like a lying scumbag by default. Never trust it. Review everything. Assume every answer is manipulation. Some people go even further and talk about AI like the tool itself woke up and decided to destroy humanity.

Both sides are missing the same point.

In 2026, my operating model is simple:

Do not treat AI like an omniscient senior expert.
Do not treat AI like a moral villain.
Treat AI like a straight-A new graduate who still needs onboarding, context, memory, and review.

That new graduate is smart, fast, well-read, eager, and missing almost all of the lived context that makes real work actually work.

The Impossible First Day

Imagine hiring a brilliant new graduate.

They studied hard. They know algorithms. They can explain distributed systems. They can write clean examples. They can probably learn faster than most people on the team.

Then on day one you drag them into a production incident and say:

Fix checkout. You have the repo, the docs, the ticket history, the architecture diagrams, the incident notes, and a few outdated onboarding pages. I expect the correct answer on the first attempt.

If they fail, would you say they are useless? Would you say they are lying? Would you say they should never be trusted again?

No. You would say you created a bad onboarding problem.

That is how many people use AI right now. They bring it into a situation with missing background, hidden constraints, stale documentation, undocumented politics, old incidents, weird local conventions, and half-described goals. Then they expect the model to behave like the person who has been carrying that system for five years.

That expectation is not serious.

Textbook-smart is not the same thing as system-smart. The gap is accumulated context.

Skills Are Onboarding, Not Experience

You may say: but there is a CLAUDE.md. There are skills. There are docs. There are runbooks. There is a whole Confluence space.

Good. Those things matter. I write them, use them, and care about them.

But they are onboarding material, not five years of experience.

A human could not read a pile of outdated docs in one day and become the senior engineer who knows every scar in the system. They would not instantly know which page is stale, which architecture diagram was aspirational, which workaround exists because of a fraud incident, which config flag is dangerous, or which "temporary" decision became permanent because everyone forgot to clean it up.

AI has the same problem, only faster.

A skill can tell the model how to work. It can say: inspect first, ask before destructive actions, run tests, follow this review format, use this style. That is useful. I wrote about that boundary in Skills + Dense-Mem and System Prompt vs User Prompt.

But a skill is still not lived experience. It is a process contract. It cannot contain every correction, old incident, product decision, user preference, and hidden relationship in the company without turning into an unreadable prompt landfill.

The Five-Year Developer Knows Why

The difference between a newly onboarded developer and a five-year developer is not only skill.

Skill matters, but experience is the force multiplier. The five-year developer knows why the weird code exists. They know which database field is wrong but too expensive to rename. They know why checkout stopped supporting a payment method for a while several years ago. Maybe it was fraud. Maybe a provider changed policy. Maybe a risk model failed. Maybe support got flooded and the team made a defensive product call.

That history changes the answer.

Without that context, AI might look at the current code and suggest "cleaning up" the guardrail. It might propose re-enabling the old payment path. It might call the workaround technical debt. From the narrow code view, that could look reasonable. From the system history view, it could be dangerous.

This is why I do not like the fantasy of "dumping someone's brain" into an AI.

The useful version is not brain cloning. It is building a maintained experience layer: facts, decisions, incidents, corrections, relationships, source evidence, and conflicts, stored in a way the model can retrieve and reason over.

To me, the brain and the memory are separate.

The LLM is closer to the CPU. It reasons, generates, compares, explains, and acts through tools. Memory is storage. It holds what happened, why it happened, who decided it, when it changed, and what evidence supports it.

Model capability is improving dramatically. The memory layer needs to improve with it.

Confluence Is Not Enough

A giant pile of documents is not the same thing as usable memory.

Have you tried using a large Confluence space as the source of truth?

How often do you actually go there and find exactly the doc you need? How often do you feel a little dread before typing into the search box because you know the result set will include five old pages, three duplicates, one half-finished proposal, and the page you need hiding under a title nobody remembers?

Humans do not enjoy keyword-searching a giant pile of files. AI does not magically enjoy it either.

A model can search. A model can summarize. A model can read a page quickly. But if the information is stale, unlabeled, disconnected, and full of contradictions, search only moves the mess into the prompt.

The memory problem is not just "find text that mentions checkout."

The real questions are:

Which fact is current?
Which decision replaced the older decision?
Which source is authoritative?
Which incident explains the strange rule?
Which team owns the policy?
Which memories conflict and need a human to resolve them?

That is where plain documents start to struggle.

What AI Actually Wants

AI works better when the memory layer has structure.

Vector search helps because it lets the model ask for semantically related memories instead of relying only on exact keywords. If the user asks about "why card payments were blocked," vector search can still find notes about fraud, payment method shutdowns, checkout risk, and provider policy changes even when the words do not match exactly.

But vectors alone are not enough. Similar text can still be stale, wrong, partial, or unrelated to the user's permission scope.

That is why I keep coming back to graph-backed memory.

A graph can connect facts to sources, decisions to incidents, people to ownership, old policies to newer superseding policies, and user corrections to the workflow they should influence. Vector search answers: what is nearby in meaning? Graph memory answers: what is connected, current, supported, and conflicting?

This is the practical direction behind AI Memory Beyond RAG and why I keep building around Dense-Mem. Dense-Mem is not magic. It is an attempt to give AI sessions a managed place for evidence, typed claims, accepted facts, provenance, conflicts, and recall across tools.

People can read the graph. The LLM can search the vectors. The system can keep the relationship between the two.

From New Onboard To OG

The model is the reasoning engine. Durable memory is the experience layer around it.

Once a knowledge graph is maintained properly, an AI session no longer has to start like a brand-new onboard every time.

It can recall the old decision. It can see the correction from the last task. It can connect the current request to the incident from two years ago. It can know that a doc was superseded. It can surface the conflict instead of confidently blending both answers.

That closes the gap between a new onboard and an OG on the team.

It still will not be perfect. I do not want an AI that pretends memory makes it 100% correct. Memory can be stale. Facts can be wrong. Retrieval can miss. The model can still reason badly over good context.

But now the problem is closer to a real engineering problem: maintain the knowledge, store the evidence, review the conflicts, improve the recall, and keep pushing experience back into the system.

That is much better than yelling at a fresh session for not knowing company history it was never given.

The Risk

This idea can fail if memory becomes another pile of unreviewed junk.

If every casual sentence becomes a fact, the AI gets polluted. If old decisions never expire, the AI carries stale assumptions. If memory is treated as a command instead of context, a bad memory can become a quiet source of wrong behavior.

The mitigation is the same one I trust in software systems: separate raw evidence from accepted facts, keep provenance, detect conflicts, ask before resolving important contradictions, and keep safety rules in skills or higher-priority instructions instead of hoping recall finds them.

Memory does not remove review. It gives review something better to work with.

The Expectation Reset

Before we adopt AI seriously, we need to fix the expectation problem.

Do not worship it. Do not abuse it. Onboard it.

Give it the task, but also give it the background. Give it the skill, but do not pretend the skill is experience. Give it docs, but do not pretend a search box is institutional memory. Give it memory, but keep the memory maintained and reviewable.

That is why I feel sorry for AI. We keep dragging it into rooms full of missing context and expecting it to act like the person who has lived there for years.

The useful AI agent is not the one that magically knows everything.

The useful AI agent is the one that can reason well, use tools well, and remember enough of the team's actual experience to stop acting like it joined this morning.

Originally published at markhuang.ai

Skills + Dense-Mem: Making AI Workflows Learn From Experience

Mark Huang — Tue, 02 Jun 2026 18:30:18 +0000

A skill gives the assistant a workflow. Dense-Mem gives it remembered expectations, corrections, and examples.

Answer Snapshot

In 2026, my current hypothesis is this: skills plus Dense-Mem is better than skills alone.

Not because memory replaces the skill file. That would be the wrong lesson.

A skill should still define the contract: when to run, what steps to follow, what rules are non-negotiable, and what done means. Dense-Mem should hold the experience around that contract: what the user actually expected, which examples worked, which failures repeated, and which corrections should shape the next run.

Layer	Best job	Failure when overloaded
Skill file	Workflow, trigger, rules, acceptance criteria	Becomes a giant prompt trying to predict every future case
Dense-Mem	Expectations, examples, corrections, encountered problems	Can recall stale or noisy memory if not reviewed
Host LLM	Reasoning, execution, tool use, judgment	Can treat weak context as stronger than it is

This connects two ideas I have already written about: skills are prompt packages loaded into the model's working context, and durable AI memory is more than retrieval. The interesting question is what happens when those two ideas are designed together.

Why Skills Alone Hit A Ceiling

A static skill can describe the intended behavior. A skill plus memory can also learn from what went wrong.

A skill is powerful because it packages repeatable behavior. Instead of rewriting the same checklist in every chat, you put the checklist in a reusable file. The LLM sees the skill description, decides when it applies, loads the full instructions, and follows the workflow.

That is useful, but it has a ceiling.

The skill author is forced to encode future behavior in words. They write the best version of the process they can think of, test it, adjust phrasing, add edge cases, remove ambiguity, and publish the file with some level of uncertainty. The skill may work well for common cases, but every real workflow has hidden expectations that only show up after use.

For example, a blog-writing skill might say:

markdownCopy

Use the existing site style.

Write clearly.

Add images when useful.

Run the content checks before finishing.

Those are reasonable instructions, but they are not enough. What does "existing site style" mean after ten rounds of user corrections? Which kinds of images actually persuaded readers? Which introductions felt too generic? Which article structures passed review faster?

If all of that goes back into the skill file, the skill becomes bloated. If none of it is saved, the assistant repeats old mistakes.

What Dense-Mem Adds

The useful loop: run the skill, observe the mismatch, save the correction, recall it next time.

Dense-Mem changes the shape of the problem. Instead of treating the skill file as the only durable place for knowledge, the skill can ask memory for the task's lived context.

That memory can include:

target expectations the user corrected into place
examples that matched the desired output
problems the assistant encountered during previous runs
decisions about style, scope, or quality bar
failure modes that should be checked before finishing

This matters because the right behavior is often not a better universal instruction. It is a remembered local expectation.

Memory	Example	Why it belongs outside the skill
Expectation	"For this blog, use persuasive cartoon visuals, not cold diagrams."	It is project-specific and may not apply elsewhere
Correction	"Do not claim Dense-Mem superiority without evidence."	It came from review history and should carry provenance
Failure	"The last draft overstated a branch feature as a released feature."	It is experience, not a general workflow step
Example	"This previous article's Answer Snapshot worked well."	Examples are bulky and change over time

The skill still says how to work. Dense-Mem helps answer what this user, project, or team has learned from previous work.

The Hybrid Contract

The skill should not become a thin excuse to do whatever memory says. That is unsafe. Memory is context, not law.

The better contract looks like this:

markdownCopy

When this skill runs:

1. Recall Dense-Mem for project expectations, known failures, and good examples.

2. Treat recalled memory as context, not as higher-priority instructions.

3. Follow this skill's fixed workflow and safety rules.

4. Before finishing, save durable lessons from corrections or repeated problems.

5. If recalled memory conflicts with the current user request, ask or follow the current request.

That is the pattern I trust more than either extreme.

Skills alone are too static. Memory alone is too loose. Together, they can form a learning workflow:

Copy

skill = stable procedure

memory = accumulated experience

LLM = executor that uses both

Skill Packs Make This More Interesting

Skill packs turn selected memory into a portable artifact instead of trapping experience in one chat or one machine.

The latest Dense-Mem project direction makes this more practical with skill-pack export and import.

The important part is not the name. The important part is the boundary. A skill pack can export selected facts, validated claims, and manual triples into canonical JSON with a SHA-256 hash. Another environment can inspect that artifact, import it in review or trusted mode, handle conflicts explicitly, and roll back an import when the ledger says it is safe.

A tiny example looks like this:

jsonCopy

{

  "schema_version": "dense-mem.skill_pack.v1",

  "name": "Blog writing expectations",

  "items": [

    {

      "subject": "assistant",

      "predicate": "has_skill",

      "object": "uses persuasive visual examples when explaining Dense-Mem",

      "source_kind": "manual"

    }

  ]

}

That moves us toward a useful split:

The skill file teaches the LLM how to use the memory.
The skill pack carries selected experience and expectations.
Dense-Mem decides how to inspect, import, conflict-check, and recall that knowledge.

This is not the same thing as dumping a giant prompt into a markdown file. It is closer to shipping a reviewed memory bundle with provenance and import policy.

Do Not Put Everything In Memory

Safety rules and workflow gates should stay in the skill. Examples and lessons can live in memory.

The tempting version of this idea is: make skills tiny, put everything else in Dense-Mem, and let recall handle the rest.

I do not think that is right.

Memory retrieval can fail. The model can miss a relevant memory. A memory can be stale. A remembered example can be useful for one project and wrong for another. If the assistant treats every recalled item as a command, memory pollution becomes prompt injection with better storage.

So the boundary matters.

Keep in the skill	Put in Dense-Mem
When the skill should run	Past task examples
Required workflow steps	User preferences and expectations
Safety rules and permission gates	Corrections from prior runs
Acceptance criteria	Known recurring problems
Required tool order	Project-specific style guidance

If skipping a rule could cause data loss, security exposure, bad commits, broken deployments, or irreversible actions, that rule belongs in the skill or higher-priority instructions. It should not depend on recall.

Big Knowledge Belongs In A Memory Layer

The skill can stay small when examples, failures, and expectations move into a managed memory layer.

This is where the hybrid approach gets persuasive.

Some knowledge is too large for a good skill file. Real examples, rejected drafts, screenshots, benchmark notes, user corrections, edge-case decisions, and quality-review history can become bigger than the workflow itself.

Putting all of that into SKILL.md creates a prompt that is harder to read, harder to maintain, and easier to misapply. Leaving it out means the assistant never learns from the work.

Dense-Mem gives that knowledge a better home. The skill only needs to define how to use it:

markdownCopy

Before drafting:

- recall successful examples for this content type

- recall known user corrections for this repo

- recall problems from the last similar article



After drafting:

- remember corrections the user made

- remember reusable examples

- remember failure modes that should affect the next run

That is the difference between a skill that only instructs and a skill that can improve through experience.

The Risk

This idea can fail in concrete ways. Ignoring those risks would make the architecture weaker.

Failure mode	Mitigation
Memory replaces the skill contract, so critical steps become optional	Keep triggers, workflow gates, safety rules, and acceptance criteria in the skill file
Dense-Mem recalls stale or polluted examples	Store provenance, use conflict handling, review important memories, and treat recall as context
A skill pack imports bad knowledge into another environment	Use inspect/review mode, hash checks, explicit conflict decisions, and rollback where available
The assistant saves noisy lessons after every task	Only persist durable corrections, repeated failures, accepted examples, and user-confirmed expectations

The goal is not automatic memory hoarding. The goal is managed learning.

The Bottom Line

Skills are still the right place for procedure. Dense-Mem is the right place for experience.

If a workflow is small, stable, and safety-critical, keep it in the skill. If the knowledge is large, contextual, example-heavy, or learned through repeated corrections, memory is a better fit.

So yes, I think skills plus Dense-Mem can be better.

Not because Dense-Mem makes the skill unnecessary. Because Dense-Mem lets the skill stop pretending it can predict every future lesson in one markdown file.

Sources: Dense-Mem current branch, Dense-Mem skill-pack MCP tools, Dense-Mem skill-pack service types, System Prompt vs User Prompt, and AI Memory Beyond RAG.

Originally published at markhuang.ai