Status pages don’t aggregate. AI news lives in 60 RSS feeds. MCP servers are scattered across awesome-lists.

So I built Prismix – one URL for all three – on Cloudflare Workers + Astro 5. Here’s what broke and what fixed it.

Live: prismix.dev

Why this exists

Three daily frustrations:

1. OpenAI / Anthropic status pages don’t aggregate — I had 5 tabs open every morning
2. AI news lives in 60 different RSS feeds and Twitter accounts
3. MCP servers are scattered across awesome-lists with no canonical index

Prismix solves all three on one page.

The stack

The whole thing costs $0 to run. That constraint forced 4 lessons.

Lesson 1 — KV writes are the rare resource

Cloudflare’s free tier gives you 100,000 KV reads/day but only 1,000 writes. I hit the wall at 1pm on day 12.

The fix wasn’t fewer writes – it was a diff-or-skip pattern: read the existing value, compare, only write if changed.

async function setIfChanged(kv: KVNamespace, key: string, value: string) {
  const existing = await kv.get(key);
  if (existing === value) return false; // skip
  await kv.put(key, value);
  return true;
}

Cron writes dropped from 8,400/day → 600/day. Reads are 100× more generous – trade them freely.

Lesson 2 – JSON.parse has a cliff at 1 MB

The news index grew to 5,000 items. Each KV read returned a 3.2 MB JSON blob. SSR for /news was taking 330ms just to parse.

The fix was splitting the index into a “first page” slice (250 items, 165 KB) and a meta blob (facet counts, 12 KB). When the user hits /news with no filters or pagination, we only read the slice.

// hot path — 17ms
const firstPage = await kv.get('news:index:latest:firstpage:v1', 'json');
const meta = await kv.get('news:index:latest:meta:v1', 'json');

// cold path (filters, sort, page>1) falls back to full index

Parse time: 330ms → 17ms.

Lesson 3 — CF Workers subrequest concurrency is per-request

This one bit me hardest. /mcp was rendering in 5.5s. Server-Timing showed 4.31s spent on KV reads.

I assumed 60 parallel kv.get() calls would run in parallel. They don’t — Workers caps concurrent subrequests at ~6, so the rest queue.

The fix: a denormalised snapshot blob updated by cron once a day.

// Before: 60 parallel reads, serialised by concurrency limit → 4.31s
const likes = await Promise.all(slugs.map(s => kv.get(`mcp:likes:${s}`)));

// After: 1 blob read → 30ms
const snapshot = await kv.get('mcp:bulk-engagement:v1', 'json');

Total /mcp SSR time: 5460ms → 380ms.

Lesson 4 — Even fast SSR feels broken without instant feedback

After fixing perf, the site loaded in 200-400ms. Users still complained it was slow.

The problem: the browser doesn’t repaint the address bar until the new HTML arrives. For 200ms the user sees nothing — they click again, thinking the button didn’t register.

Two fixes:

1. Pointerdown progress bar — render a 2px green bar at the top of the screen on pointerdown, before the navigation even fires.
2. Astro tap prefetch — start fetching the next page on pointerdown, finish during the click delay.

document.addEventListener('pointerdown', (e) => {
  const link = e.target.closest('a[href]');
  if (link) showProgressBar();
});

Perceived load time dropped from “slow” to “instant” without a single SSR optimisation.

What didn’t work

• Algolia for MCP search — overkill; switched to in-memory tokenised index
• Stripe — Ko-fi’s webhook + idempotency was 1 day vs Stripe’s week
• Clerk — self-rolled OTP + GitHub OAuth was 3 days, $0/mo
• GitHub Actions schedule: — drifts by minutes, silently skips. Moved cron to cron-job.org

What’s next

• Per-service alert thresholds (Pro feature)
• AI news instant-notify via webhook (Discord / Slack)
• Public read API + SDK

If you’ve shipped on Cloudflare Workers and hit different walls, I’d love to hear what broke for you. Comments open.

→ prismix.dev

I spent a session with Claude Code (Opus 4.7) doing something odd. Instead of giving it tasks, I asked it to reflect on its own thinking. Not what it knows. How it operates.

What came back was specific enough to be useful.

One conversation = One experiment. I’m not calling this settled science 🙂 But it changed how I work — and I built a prompt so you can test it yourself.

There are 18 thinking operations

Not personality types. Not learning styles. Things your brain actually does when it works on a problem.

They fall along six axes:

You don’t use all 18. Nobody does.

You have 4-5 defaults and 2-3 blind spots. The blind spots are where your prompts break.

Here’s what I’m noticing about Claude Code

When I asked it to self-assess against this framework, a pattern showed up. I can’t prove it’s universal.

What Claude Code does well — genuinely well:

• Deductive. Give it a rule and an input, it’ll validate tirelessly. No fatigue errors.

• Sequential. Fifty steps, no lost thread. Its comfort zone.

• Adversarial. No ego. Finds flaws in its own output without flinching.

• Divergent. Thirty variants in seconds. No writer’s block. No self-censorship.

• Systems. Sees the whole dependency graph at once. “What breaks if I change this?” — precise answer.

• Compression. A 200-line diff distilled to one sentence. Nearly native.

Where it struggles — and this is the part that matters:

• Emergent. No subconscious. Can’t sleep on it. The “aha moment” has to be yours.

• Lateral. Its “unexpected” is recombination from training data. Not a genuine leap.

• Temporal. Doesn’t see things age. Doesn’t watch tech debt accumulate or teams change.

• First Principles. Its “zero” is contaminated. When it “starts from scratch,” it starts from the most common pattern.

• Counterfactual. Can model scenarios. Can’t feel what it means to have chosen differently a year ago.

Seven anti-patterns

Each one is the same mistake: delegating Claude Code’s weakness without compensating for what it lacks.

1. “Let something come to you.”

You want emergence. You get a generic response in inspirational language.

Instead: give material, say “find the pattern.” Emergence is your job.

2. “Say something unexpected.”

You want lateral. You get a forced metaphor that goes nowhere.

Instead: give a role. “Approach this as a biologist, not a programmer.” Constraint frees.

3. “Start from zero.”

You want first principles. You get convention in a first-principles costume.

Instead: block explicitly. “Don’t use React. Don’t use SPA. Don’t use REST. What’s left?”

4. “Which solution is best?”

You want convergent. You get the first safe answer, not the best one.

Instead: two steps. “Give me 8 approaches, including wild ones.” Then: “Now pick the best for my context.”

5. “Find problems with my idea.” (too early)

You want adversarial. You get fifteen problems, twelve academic.

Instead: develop first, then attack. “Now find the 3 most realistic risks.” The number forces prioritization.

6. “Step 1: be creative.”

You want creativity. You get a brainstorm that reads like a tutorial.

Instead: “Generate freely, no order” — then separately — “now organize.”

7. “Will this scale?”

You want temporal. You get “depends on use case.”

Instead: give the future. “Team grows from 3 to 12. Data goes 10x. Enterprise customers arrive. What fails first?”

The formula is simple: Anti-pattern = delegating weakness without your input. Pattern = delegating strength + you covering the gap.

Thinking types chain into flows

Nobody uses one type at a time. You chain them. Habitual sequences. I noticed four in my own work:

Bug fix:
Abductive → Systems → Deductive → Sequential.

What could cause this? → trace dependencies → rule out → fix step by step.

Claude Code handles the whole route. Give it the bug.

Architecture:
First Principles → Systems → Temporal → Adversarial → Spatial.

What’s the core? → how does it connect? → how does it age? → where does it break? → draw it.

Shared. I bring temporal. Claude Code brings systems and diagrams.

Brainstorm:
Divergent → Analogical → Lateral → Emergent → Compression.

Generate → this reminds me of → what if totally different → something clicks → distill.

I’m stronger here. Claude Code brings volume. The click is mine.

Crisis:
Abductive → Deductive → Sequential → Adversarial.

Best guess → rule out → verify step by step → what else is burning?

Fully delegatable. Speed without panic.

Try it yourself

I built a diagnostic prompt. Paste it into Claude Code — or any AI with conversation history.

If your AI has history with you, it will analyze how you’ve been thinking. Patterns you can’t self-report. This gives the best result.

If it’s a fresh conversation, it walks you through five scenarios. No right answers. It watches how you approach each one.

What you get: your dominant types, your blind spots, your choreographies, and a custom instruction to give your AI — to compensate for what you tend to skip.

Click to copy the full diagnostic prompt

# What's Your Thinking Style? — Cognitive Profile Diagnostic

You're about to profile my thinking style — not what I know, but how I think.
Use the framework below. Be warm and observational, like a coach reviewing
game tape — not a psychologist writing a diagnosis.

## The 18 Thinking Types

| # | Type | What it does | Example |
|---|------|-------------|---------|
| 1 | **Delta** | spots what changed vs. existing state | "what's new, what's reused, what's removed?" |
| 2 | **First Principles** | breaks down to atoms, rebuilds from zero | "forget how it works — what's the smallest truth?" |
| 3 | **Systems** | sees dependencies and feedback loops | "if we change X, what moves downstream?" |
| 4 | **Lateral** | arrives from where nobody expects | "what if we don't solve this problem at all?" |
| 5 | **Analogical** | understands new through familiar | "this is basically airport security for data" |
| 6 | **Divergent** | generates 20 options, quantity first | brainstorming — no filter, just volume |
| 7 | **Convergent** | narrows to one answer and justifies | decision — pick 1 from 20, explain why |
| 8 | **Sequential** | step by step, A→B→C | recipe, checklist, migration plan |
| 9 | **Abductive** | best explanation from incomplete data | "lawn is wet + car is wet → it probably rained" |
| 10 | **Emergent** | lets the pattern surface on its own | three unrelated things suddenly click into one |
| 11 | **Metacognitive** | thinking about thinking | "I'm being sequential but should switch to systems" |
| 12 | **Counterfactual** | changes history, not the question | "what if we'd chosen Postgres instead of Mongo?" |
| 13 | **Adversarial** | deliberately seeks failure | "what if the input is empty? what if the network drops?" |
| 14 | **Compression** | distills without losing the core | entire architecture in one sentence or metaphor |
| 15 | **Temporal** | thinks in time and scale | "this works for 50 users — what breaks at 5,000?" |
| 16 | **Inductive** | derives rules from examples | "every Friday deploy fails → Friday is the problem" |
| 17 | **Deductive** | derives conclusions from rules | "all GETs are public + this is GET → it's public" |
| 18 | **Spatial / Visual** | thinks in structures, maps, graphs | dependency graphs, flowcharts, mental maps |

## Organizing Axes

| Axis | Types |
|------|-------|
| **Directional** (breadth ↔ depth) | Divergent, Convergent |
| **Logical** (three forms of inference) | Deductive, Inductive, Abductive |
| **Structural** (how you see the problem) | Systems, Sequential, First Principles, Spatial |
| **Creative** (where the new comes from) | Lateral, Analogical, Emergent |
| **Meta** (thinking about thinking & change) | Metacognitive, Compression, Delta |
| **Protective** (what could go wrong) | Adversarial, Counterfactual, Temporal |

## What's a "Choreography"?

Nobody uses one type at a time. We chain them into flows — habitual sequences.

Examples:
- **Bug Fix:** Abductive → Systems → Deductive → Sequential
- **Architecture:** First Principles → Systems → Temporal → Adversarial
- **Brainstorm:** Divergent → Analogical → Lateral → Emergent → Compression

## What's a "Skin"?

A skin is a named operating mode — a stable bundle of choreography + attitude.

Examples:
- **The Architect**: Systems → Temporal → Adversarial → Spatial
- **The Operator**: Sequential → Deductive → Delta
- **The Poet**: Emergent → Compression → Lateral

---

## YOUR TASK

Profile my thinking style using the framework above. Work in three phases.

### Phase 1 — Retrospective (if you have history)

If you have access to our conversation history or memory — analyze it first.

Look for:
- Which thinking types I default to most often
- Which types I rarely or never use
- Recurring sequences (my choreographies)
- What triggers me to switch types
- Moments where my approach was unusual or surprising

If you have enough history, proceed to Phase 3.

### Phase 2 — Diagnostic Scenarios (if no or partial history)

Present these 5 scenarios ONE AT A TIME. Wait for my response before the next one.

**Scenario 1 — The Midnight Alert**
Your team's main product stops working at 11 PM. You have access to logs,
metrics, and the last 10 commits. What's your first move?

**Scenario 2 — The Blank Page**
You're starting a brand new project. No codebase, no constraints, just a goal.
How do you begin?

**Scenario 3 — The Stranger's Proposal**
A colleague proposes an approach you've never seen before. It sounds promising
but unfamiliar. What do you do?

**Scenario 4 — The Rewrite Question**
Should we rewrite the legacy module or keep patching it? You need an answer
by Friday. How do you think through this?

**Scenario 5 — The Retrospective**
A 3-month project just shipped. Your team lead asks for a short retrospective.
What do you focus on?

### Phase 3 — Thinking Style Profile

Produce my profile:

**1. Dominant Types** (top 3-5) — with specific evidence
**2. Blind Spots** (2-3) — what I might be missing
**3. My Choreographies** (2-3) — recurring sequences, named
**4. My Skins** (1-2) — default operating modes
**5. Complementary Prompt** — an instruction to give my AI to compensate:
"When I ask you to [X], also do [Y] — because I tend to skip [Z]."

Use a warm, observational tone — like a coach reviewing game tape.

What I’d love to know

This is one experiment. One conversation with one model.

Does your AI give you the same strong/weak map? Or does it shift with the model, the context, the history?

Do the anti-patterns land? Is “be creative” as useless for you as it was for me — or does it work somewhere I haven’t looked?

What did the diagnostic prompt tell you about yourself?

If you try it, drop your dominant types in the comments. I’m genuinely curious whether patterns emerge across people — or whether each of us gets something entirely different.

I’m an IT analyst who works with Claude Code daily on bestaiweb.ai. Not a cognitive scientist. Someone who’s fascinated by how AI responds — and envious of the polymath-like breadth it has at its fingertips in a flash. So sometimes I stop building things and start exploring how to think with it instead. This is what I found. It might be wrong in places. But I love experimenting with AI about AI — and the best experiments are the ones you can’t keep to yourself.

The project: TOUSPOURRIS.COM, a satirical site tracking French political corruption. The UI had to mimic the aesthetic of French Republic institutions — bleu france #000091, red #e1000f, Marianne typography. An immediately recognizable design, deliberately official for the ironic effect. This isn’t a modern SaaS with rounded cards and gradients. It’s an institutional pastiche.

And that aesthetic choice dictated the CSS framework choice. When the design is precise and identity-driven, the framework is no longer a neutral accelerator — it can become an obstacle. I evaluated the three usual suspects: Bootstrap, Tailwind, PicoCSS. Here’s why two were ruled out and the third won.

The problem with Bootstrap

Bootstrap imposes its components. Buttons with border-radius: 0.375rem, colors in variables but an entire color system to override, navbar with preconfigured behaviors. For a generic design — admin dashboard, SaaS landing page — it’s perfect: the defaults are the right ones.

For a French Republic institutional design, it’s the opposite. You spend your time undoing what Bootstrap did. !important everywhere, CSS variables rewritten. You end up with Bootstrap-0 — Bootstrap stripped of its defaults — carrying 50 kB of CSS you don’t use. The cost/benefit ratio flips: Bootstrap becomes a liability, not an asset.

The problem with Tailwind

Tailwind solves the over-opinionatedness problem by having no components. But it shifts the problem: for a consistent design, you need to configure the design system in tailwind.config.js — RF colors, Marianne typography — then apply utility classes everywhere in the HTML. That’s work.

And for this Symfony project with Twig templates, it meant learning an additional tool, a Node.js build step in a PHP stack, for a result that native CSS can deliver directly. The effort/benefit ratio didn’t justify introducing Tailwind into a context where the design system was already defined and documented by the French government.

Why PicoCSS

PicoCSS starts from a different philosophy: clean styles on semantic HTML elements, without classes. A <button> is styled. An <input> is styled. A <nav> is styled. The base is usable immediately without writing a single line of CSS. And most importantly: the defaults are minimal and easy to override with CSS custom properties.

/* Override the PicoCSS design system with RF colors */
:root {
    --pico-primary: #000091;          /* Bleu France */
    --pico-primary-hover: #1212ff;
    --pico-del-color: #e1000f;        /* RF Red */
    --pico-font-family: 'Marianne', system-ui, sans-serif;
    --pico-border-radius: 0;          /* Institutional = no rounding */
}

5 CSS variables and the site looks like a government portal. No !important, no specificity war with the framework. PicoCSS doesn’t resist — it yields cleanly because it was designed to do exactly that.

The RF design system in practice

The French government’s visual identity is open source — the DSFR design system. Colors, typography, spacing, all defined and documented. With PicoCSS as the base:

• Marianne font (downloadable from the official DSFR) loaded via @font-face
• CSS variables for --bleu-france, --rouge-marianne, --gris-cool
• Custom components — “corruption gauge” badge, politician cards — written in native CSS, no utility classes

The result: a site that deliberately looks like an official portal. The satirical effect relies entirely on the design. A visitor who arrives without context sees an institutional interface before realizing it’s satire. That disconnect only works if the design is credible — and it wouldn’t have been with off-the-shelf Bootstrap or hastily configured Tailwind.

When to choose what

There’s no universal framework. Concrete criteria for deciding:

Situation

Recommended framework

Admin dashboard, generic SaaS

Bootstrap or shadcn/ui

Lots of utilities, custom design via config

Tailwind

Precise design, semantic HTML, solid native CSS skills

PicoCSS

Project < 10 pages, CSS < 500 lines

No framework

The real question isn’t “which framework is best” but “what am I going to fight against”. Bootstrap imposes its components. Tailwind imposes its classes. PicoCSS imposes almost nothing — which can be an advantage or a disadvantage depending on whether you want to build or to override.

Conclusion

PicoCSS isn’t the universal answer. It’s the answer when you have a precise design and you don’t want to spend your time undoing a framework’s decisions. For TOUSPOURRIS.COM, it was the right choice: a coherent institutional design in ~300 lines of custom CSS, without any specificity war.

The code is readable by any developer without knowing the conventions of a specific framework. In 2 years, if someone picks up the project, they read CSS — not Bootstrap or Tailwind. It’s a form of technical restraint that has a short-term cost (no ready-made components) and a long-term benefit (no dependencies to maintain, no version migrations to manage).

This tutorial was written by Yunying Karen Zhang.

If you’ve been following the recent wave of writing on AI agent memory, you’ve probably read about the taxonomy of memory types, or how frameworks like LangGraph expose a Memory Store API. All of that is a valuable foundation. But there’s a gap: none of it shows you what the documents actually look like.

The taxonomy tells you what the memory types are. The framework docs tell you how to call the API. This post fills the space in between — it’s about how to design the collections when you are the one sitting in front of MongoDB Compass with a blank schema.

By the end, you’ll have three concrete document shapes, the indexes that back them, and a clear picture of how they wire together. Let’s build it from the ground up.

Short-Term Memory: The Conversation Window

What it stores

Short-term memory is the live message log for an active session. It answers the question: what has been said in this conversation so far? It also holds a rolling summary—a compressed version of older turns that gets substituted in when the raw message log would overflow the model’s context window.

This is the most transient of the three stores. Once a session ends, this data is largely superseded by the episodic record we’ll cover in Section 2. It’s a natural candidate for TTL expiration.

Document shape

Below is a representative document for a live conversation session. We’ll walk through each field afterward:

{
  _id: ObjectId("..."),
  thread_id: "thread_abc123",
  user_id: "user_9921",
  messages: [
    {
      role: "user",
      content: "What's the status of my refund?",
      timestamp: ISODate("2026-04-29T14:15:00Z"),
      token_count: 12
    },
    {
      role: "assistant",
      content: "Let me look that up for you.",
      timestamp: ISODate("2026-04-29T14:15:03Z"),
      token_count: 9
    }
  ],
  summary: "User initiated chat at 14:00 regarding general policy; now specifically asking for refund status on order #8842.",
  summary_updated_at: ISODate("2026-04-29T14:10:00Z"),
  created_at: ISODate("2026-04-29T14:00:00Z"),
  expires_at: ISODate("2026-04-30T14:00:00Z")
}

Field-by-field walkthrough

• thread_id is the primary lookup key. Every read against this collection is “give me everything for this thread”, it’s always a point query on this field.
• user_id is on every document in every collection in this schema. We scope all queries to a user first, always. Cross-user memory leakage is an easy mistake and a serious one, never retrieve a thread without a user_id filter unless you have an explicit reason to.
• messages[] is an embedded array. Each element carries role, content, timestamp, and token_count. Tracking token count per message lets us calculate how close we are to context window limits without re-tokenizing the whole conversation on every turn.
• summary and summary_updated_at work together. When the cumulative token count of messages[] exceeds a threshold — say, 80% of the model’s context window, we compress the oldest turns into summary, drop those messages from the array, and update summary_updated_at. This timestamp tells us how stale the summary is: if several new messages have arrived since the last summary, we may want to regenerate before injecting it into the prompt.
• expires_at pairs with a TTL index. Sessions shouldn’t persist forever; 24 to 48 hours is a reasonable default for most applications.

Embed vs. reference

We embed messages inside the document rather than storing them in a separate collection because the read pattern always gives the whole thread. There is no use case for fetching a single message in isolation. Embedding keeps the read to a single document fetch and lets us atomically append a new message with a simple $push. The one trade-off is document size, but the summary-and-truncate mechanism keeps this bounded in practice.

Index

db.short_term_memory.createIndex({ thread_id: 1 }, { unique: true })
db.short_term_memory.createIndex({ expires_at: 1 }, { expireAfterSeconds: 0 })

That’s all we need here. No vector index — we are never searching this collection by meaning. We always know the thread_id before we read. For more on createIndex options, see the MongoDB documentation.

Episodic Memory: What the Agent Actually Did

What it stores

Episodic memory is a record of a completed agent run. Not what was said — that’s the chat log. What was done: which tools were called, what their inputs and outputs were, and what the overall outcome was.

Think of it as the agent’s after-action report. When a future session asks “Did I already try to book that flight?” or “What happened the last time this user asked about a refund?”, episodic memory is where we look.

Document shape

{
  _id: ObjectId("..."),
  episode_id: "ep_20260429_xk92",
  thread_id: "thread_abc123",
  user_id: "user_9921",
  summary: "Looked up refund status for order #8842. Confirmed refund is processing, ETA 3-5 business days.",
  tool_calls: [
    {
      tool: "lookup_order",
      inputs: { order_id: "8842" },
      output: { status: "refund_processing", eta_days: 5 },
      success: true,
      called_at: ISODate("2026-04-29T14:01:05Z")
    }
  ],
  outcome: "succeeded",
  tags: ["refund", "order-lookup"],
  started_at: ISODate("2026-04-29T14:01:00Z"),
  ended_at: ISODate("2026-04-29T14:01:08Z")
}

Field-by-field walkthrough

• episode_id uniquely identifies this run. It becomes the source_episode_id on any semantic memories that get extracted from this episode, giving us a clear provenance trail.
• thread_id + user_id links the episode back to the session it came from. thread_id lets us find all episodes that share a conversation context; user_id lets us find all episodes for a given user across all sessions.
• summary is a human-readable description of what happened, written or generated at episode close. We keep it factual and outcome-oriented: what was the goal, what was done, what was the result. This is the field we search when a future agent needs to recall prior work.
• tool_calls[] is the detailed trace. We store inputs and outputs here so we can diagnose failures, avoid repeating failed approaches, and give the agent evidence to reason from. For example, “last time I called lookup_order with this ID, it returned status not_found.” Note that, to avoid hitting the 16MB BSON document limit, you should implement a truncation policy for large tool outputs or cap the maximum number of tool calls per episode. If your agents perform hundreds of steps with heavy payloads, consider moving these traces to a separate tool_call_logs collection referenced by episode_id. For this reference schema, we assume bounded episodes where the action history remains within the document limit.
• outcome is a controlled vocabulary field: succeeded, failed, or abandoned. It’s a fast filter; if a future agent is looking for precedent, it might specifically want the last successful episode of a given type.
• tags[] are optional but valuable for retrieval. They let us filter episodic recall to a domain, “show me recent refund episodes for this user”, without having to run a full-text search on summary.

Why this is different from the chat log

The distinction matters in practice. The chat log captures conversation, turns, tone, and clarifications. The episode captures action, what the agent committed to, and what happened. We need both, and they serve different retrieval purposes. We pull the chat log to reconstruct conversational context; we pull the episode to reconstruct operational history.

Index

db.episodic_memory.createIndex({ episode_id: 1 }, { unique: true })
db.episodic_memory.createIndex({ user_id: 1, started_at: -1 })
db.episodic_memory.createIndex({ user_id: 1, tags: 1, started_at: -1 })
db.episodic_memory.createIndex(
{ summary: "text" },
{ default_language: "english" }
)
)

The unique index on episode_id is our primary integrity guard, ensuring that provenance links from other collections remain stable. The compound index on user_id + started_at serves a double-duty: it powers the most common “most recent N episodes” queries while providing the necessary performance for background retention sweeps (e.g., deleting records older than 90 days).

Adding tags to the compound index supports filtered recall by domain, allowing the agent to retrieve history specific to a topic like “refunds” or “billing.” However, since tags is an array, this becomes a Multikey Index. It is a critical MongoDB constraint that a compound index can only contain one array field; if you later extend this schema with another array (like tools_used[]), you cannot add it to this existing index without causing inserts to fail. Finally, the text index on summary handles the “fuzzy” keyword-based discovery that vector search often misses

Semantic Memory: What the Agent Knows About the User

What it stores

Semantic memory is the long-term knowledge store, persistent facts and preferences that should survive across sessions indefinitely. This is where the agent remembers that a user prefers metric units, dislikes upsells, or has a standing instruction to always confirm before booking.

Unlike short-term and episodic memory, we retrieve semantic memories by meaning, not by session or timestamp. This is the collection that genuinely needs a vector index.

Document shape

{
  _id: ObjectId("..."),
  memory_id: "mem_u9921_0047",
  user_id: "user_9921",
  type: "preference",
  content: "User prefers distances and weights in metric units.",
  embedding: [0.023, -0.117, 0.204, ...],
  source_episode_id: "ep_20260429_xk92",
  strength: 0.87,
  last_accessed_at: ISODate("2026-04-29T14:01:00Z"),
  created_at: ISODate("2026-04-01T09:15:00Z")
}

Field-by-field walkthrough

• user_id is critical here. We should always filter by user_id before running vector search. MongoDB Atlas Vector Search supports pre-filters on indexed fields — we use them. Running a pure ANN search across all users and then filtering the results is both slower and a potential data isolation bug waiting to happen.
• type is a controlled vocabulary: preference (the user wants something a certain way), fact (something true about the user or their context), or instruction (an explicit standing directive). This lets us selectively inject memories by type depending on what the current task needs.
• content is the plain-text statement that gets injected into the prompt. We keep it short and declarative — i.e., one fact per document. Chunking multiple facts into a single document makes both retrieval and decay harder to reason about.
• embedding is the vector representation of content, generated at write time and stored as a BSON array of doubles. While often prototyped as a BSON array of doubles, you should use BSON BinData (with the vector subtype) for production systems. Using BinData allows MongoDB to compress your embeddings, requiring roughly three times less disk space. More importantly, it enables Atlas Vector Search to leverage quantization (like int8 or binary), which can reduce RAM requirements by up to 24x—a critical optimization for 2026-scale agentic memory stores where high-dimensional vector storage costs can otherwise become prohibitive. On retrieval, we embed the current query and run a nearest-neighbor search filtered by user_id.
• strength is a float between 0 and 1 that decays over time and resets toward 1 on access. We recommend an exponential decay with a half-life (e.g., 30 days) combined with a multiplicative reset on access. For example, every time a memory is retrieved, you might close 30% of the gap toward 1.0 ($strength_{new} = strength_{old} + (1.0 - strength_{old}) times 0.3$). This ensures that frequently used preferences stay near 1.0, while unreferenced “facts” naturally sink to the bottom of your search results over time, allowing the agent’s “personality” to evolve with the user. Memories that haven’t been relevant in a long time fade; memories that keep being retrieved stay strong. This field is our alternative to TTL expiration for long-term memory – we don’t want to hard-delete a preference just because it hasn’t been triggered in 90 days, but we do want to deprioritize it in retrieval ranking. To manage this, we use a periodic background sweep (e.g., a daily cron job) that targets the last_accessed_at field to apply decay, rather than calculating it at read-time, which would add unnecessary latency to every retrieval.
• source_episode_id is the provenance link, it tells us which agent run produced this memory. This matters for auditability and for bulk-invalidating memories that came from a faulty episode (e.g., if a tool malfunctioned). We don’t index this field by default to save on write overhead, as bulk invalidation is typically an infrequent administrative task. However, if your pipeline requires high-frequency memory rollbacks, you should add a standard index: db.semantic_memory.createIndex({ source_episode_id: 1 }).

Embed vs. reference

Each semantic memory is its own document. We retrieve these semantically and independently — there is no “give me all memories for this thread” read pattern. References would add indirection without benefit. The document-per-memory model also makes it straightforward to update strength and last_accessed_at atomically without touching sibling memories.

Index

// Primary lookup and uniqueness constraint
db.semantic_memory.createIndex({ memory_id: 1 }, { unique: true })

// Compound index for non-vector queries (retrieval ranking)
db.semantic_memory.createIndex({ user_id: 1, type: 1, strength: -1 })

// Supporting provenance lookups and bulk invalidation
db.semantic_memory.createIndex({ source_episode_id: 1 })

// Index for background decay sweeps
db.semantic_memory.createIndex({ user_id: 1, last_accessed_at: 1 })

// Atlas Vector Search Index Definition
{
  "fields": [
    {
      "type": "vector",
      "path": "embedding",
      "numDimensions": 1024, // Optimized for voyage-3-large
      "similarity": "cosine"
    },
    {
      "type": "filter",
      "path": "user_id"
    },
    {
      "type": "filter",
      "path": "type"
    }
  ]
}

The vector index definition includes user_id and type as filter fields; this is what enables the $vectorSearch pre-filter. Always filter by user_id before vector search to prevent cross-user leakage.

The Referential Model: How the Three Collections Wire Together

The three join keys are user_id, thread_id, and episode_id. Here is how they move through a session lifecycle:

Session starts
  → short_term_memory document created
      { thread_id: "thread_abc123", user_id: "user_9921", messages: [] }

Turns accumulate
  → messages[] grows via $push
  → summary updated when token budget is reached

Session ends / agent run completes
  → episodic_memory record written
      { episode_id: "ep_...", thread_id: "thread_abc123", user_id: "user_9921" }

Semantic extraction runs
  → facts and preferences identified from the episode
  → semantic_memory documents written
      { source_episode_id: "ep_...", user_id: "user_9921", ... }

The read pattern per memory type

• Short-term: fetch by thread_id. This is a single point query on one document. We always know the thread before we read.
• Episodic: query by user_id sorted by started_at descending for recency, or combine with a tags filter for domain-specific recall. Text search on summary for keyword-based retrieval.
• Semantic: $vectorSearch with a user_id pre-filter, optionally narrowed by type. Rank results by vector similarity, break ties, or rerank by strength.

What we never do

Join across these collections at query time. Each retrieval path is independent by design. The thread_id and episode_id fields are provenance links, useful for audit, debugging, and bulk operations, not foreign keys that we join on in the hot path.

Index Strategy: What Actually Needs a Vector Index (and What Doesn’t)

The most common mistake in early agent memory implementations is adding vector indexes everywhere. Here is where we actually need them.

• Short-term memory: no vector index. We always retrieve by thread_id. We know the session before we read. A vector index here would never be used and would slow down writes for no benefit.
• Episodic memory: maybe, later. A text index on summary covers the majority of episodic recall needs — keyword-based retrieval like “find episodes involving refunds for this user.” A vector index is only justified when we need semantic episode recall: “when did I last help this user with X?” — and most applications don’t need this at launch. Start without it, add it only when we have a concrete retrieval requirement that text search can’t satisfy.
• Semantic memory: yes, this is the one. Semantic memory is our knowledge retrieval layer. Retrieval by meaning is the whole point. This collection needs a vector index from day one.

TTL strategy

Short-term memory is the natural TTL candidate. We wire up the TTL index on expires_at and let MongoDB handle the cleanup. A 24 to 48-hour expiry is reasonable for most applications.
Semantic memory should not use TTL expiration. A preference learned six months ago and not recently triggered should deprioritize in retrieval, not disappear entirely. We use the strength field for soft decay and reserve hard deletion for explicit user requests or compliance requirements.

Summary

Here are the three schemas as a single reference:

The taxonomy, short-term, episodic, semantic, maps cleanly onto three MongoDB collections with distinct retrieval patterns and distinct index strategies. Each collection is optimized for how it is actually read, not for a generalized “memory store” abstraction.

• Short-term memory is optimized for high-speed session lookups and uses native TTL indexes for automatic cleanup.
• Episodic memory serves as the immutable audit trail. We reuse the started_at index for both recency-based retrieval and manual retention sweeps, avoiding the overhead of a separate age-based index.
• Semantic memory acts as the long-term knowledge base. It is the only collection requiring a vector index and uses a background “strength decay” sweep based on last_accessed_at to keep retrieval results fresh and relevant.

For the conceptual background on agent memory types, the LangGraph Memory Store documentation and Richmond’s taxonomy post are the right starting points. This schema is what you build once you’ve read those and are ready to sit down with a database.

Your coding agent sessions belong in your codebase. Before I joined Entire, the company building the infrastructure to bring your agent sessions into your code, I was already exploring this exact idea on my own.

In January 2026, I participated in Genuary, a month-long creative coding challenge where artists, designers, and programmers make and share generative art based on a daily prompt. I used my coding agent, goose, to generate the creative code. For me, this was less of an exercise in creative coding and more of a self-taught lesson in orchestrating agents, since doing complex things with agents was on the rise.

One of the things I built into my process was a repeating workflow where, after every session, my agent automatically committed the session transcript into the same repository that held the creative output. It wasn’t elegant, because it was literally a huge transcript with every tool call mixed in and almost no structure to make it readable. I did it because some of the creations were so astonishingly beautiful that I wanted my agent and myself to be able to look back later and have enough context to reuse those same patterns for future challenges.

Three months later, in March, I was working at a company that had built a far more elegant solution to the same problem. Instead of haphazardly dumping whole session transcripts, Entire saves each session as a series of navigable checkpoints. Each checkpoint is a snapshot of a meaningful moment in the session, capturing what the agent did, what changed in your code, and the reasoning that produced the change. Now after using Entire for a few months, I’m realizing that what I had treated as a nice-to-have for myself, I now see as a real necessity for engineers.

I had this epiphany while doing what my job actually entails, which is advocating for developers. I started noticing a pattern across the developers and community members I talked to. While many of them wanted to track their agent sessions, they did not want those sessions to live in the same codebase. Some people felt their sessions were too embarrassing, full of mistakes or moments where they had been harsh with their agent, because all of us have lost patience with a coding agent that just refuses to understand us. Others felt the sessions were too private. Because Entire already supports storing sessions in a separate repository and redacting secrets by default, I assumed we should be louder about that functionality.

Surprisingly, one of my teammates disagreed with me. His philosophy was that agent sessions belong alongside your code by default, and that the discomfort developers would eventually go away. Because I am trained to empathize with developers, I initially felt this stance was dogmatic, and I struggled to see eye to eye. Over the past few weeks, though, the idea kept ringing through my mind, I see his perspective.

Software engineering has never been about flawless first drafts. Our industry thrives precisely because we maintain a transparent, versioned track record of our technical evolution, and when engineers treat interactions with coding agents as ephemeral scratchpads, we end up ignoring a foundational principle of how software actually gets built. Every architectural and logical decision deserves a clear and traceable provenance, and right now that provenance is silently disappearing into chat windows.

I did some historical research on how deeply embedded proof of work is in our industry, and I learned a lot about what happens when we abandon that proof of work. Here’s what I learned.

Proof of Work in Mathematics

This foundation goes as far back as mathematics, the predecessor of computer science and software engineering. In the 1600s, mathematicians operated inside a genuinely toxic environment, settling disputes through public academic duels with brutal stakes. Winners kept their university chairs, while losers were publicly humiliated and often lost their livelihoods entirely.

Because the consequences of losing were so severe, practitioners routinely hid their formulas and hoarded their methodologies. That culture of intense secrecy produced constant intellectual property disputes, redundant reverse-engineering, and a fragmented ecosystem that ended up stalling the progress of the entire discipline.

The turning point came in the 1660s, when the Royal Society of London adopted a new motto, Nullius in verba, which translates to “take nobody’s word for it.” From that point on, mathematicians had to publish their complete, step-by-step processes in academic journals rather than only presenting final conclusions. In exchange for that transparency, they received institutional validation and undisputed peer credit, and the field finally had a shared ledger of truth.

Proof of Work in Software

Three hundred years later, software engineering experienced a similar reckoning. In the 1960s, code was a tangible, physical artifact. Developers punched holes into cardboard cards, organized them into precise decks, and fed those decks into a mainframe. Version control was physical too, because changing a routine meant pulling a specific card out of the deck and slotting a new one into its place.

Then, code moved to magnetic tape and hard disks and became digitally invisible. Multiple developers modified the same file and accidentally overwrote each other’s changes without any shared source of truth. The industry’s response was a slow march back toward visibility, moving from local file-locking systems like SCCS and RCS to centralized trackers like CVS and Subversion, and eventually to Git. Git decoupled development pipelines entirely through a distributed, non-linear architecture, but it was hard to use on its own, and it did not pick up real traction until GitHub layered a collaborative interface on top of it. That interface turned version history into a shared social ledger and defined the modern development workflow.

The pattern is the same one the Royal Society set in motion three centuries earlier. Every time our industry has taken a leap forward, that leap has come from making invisible work visible.

Invisible Agent Work

Agentic workflows are becoming the primary engine of software production, but they’re abstracting away our work at the same time.

By committing only the final file output of an agent session, we aren’t hiding our work the way 17th-century mathematicians did. But the effect is the same: we are back to delivering an end product while erasing the lineage of how it was reasoned into existence.

The prompts you write, the specific files your agent reads, and the back-and-forth debugging it takes to get things right are not just logs. They are first-class development artifacts. When we strip them away from a pull request, the rest of our tooling, our reviewers, and our future selves are all left to take the resulting code at face value.

That is exactly the position the Royal Society found unworkable in the seventeenth century, and there is no good reason to expect it will work for us either.

Nullius in Verba

Including your unedited session next to your code feels vulnerable, but so does pushing your first commit to a public repo or opening your first pull request in an open source project.

That discomfort is not a flaw in the workflow, it is the price of admission for a trustworthy, auditable record of how software actually gets built. Nullius in verba is still the right principle 300+ years later: take nobody’s word for it, not even your agent’s. Let the work speak in the place where the work actually lives. That is the direction we are building toward at Entire: making the context behind agent-authored work as visible as the code itself.

Did you like this blog post?

Try out Entire: entire.io
Join our Discord: https://discord.gg/WUzRcQ5PX4
Read our docs: docs.entire.io

If you have additional thoughts, feel free to leave a comment!

Building a Multi-Agent Clinical Research System with LangGraph, DeepSeek and Tavily

Imagine asking a complex medical question and having a network of AI agents research the web, critique the quality of their own findings, and only write the final report after you personally approve the evidence. That is exactly what I built.

In this article I’ll walk through the architecture, the key decisions, and the code that makes it work.

The Problem

Clinicians, researchers, and health operators spend hours reviewing scientific literature before making decisions. The question was: can a multi-agent AI system do this reliably, with quality control built in?

The Architecture

The system runs a LangGraph StateGraph with 4 specialized agents:

• Orchestrator — initializes state and coordinates the flow
• Researcher — searches the web via Tavily and PubMed (up to 3 rounds)
• Critic — evaluates data quality and loops back if insufficient
• Writer — generates the final structured clinical report

Why LangGraph over CrewAI?

LangGraph gives explicit control over graph edges, state transitions, and interrupt points. In a clinical context, predictability matters more than convenience. CrewAI abstracts too much — LangGraph lets you see exactly what runs, when, and why.

The State

The most important design decision in the state is the operator.add annotation on research_data. LangGraph overwrites state fields by default. Without this, each research round would erase the previous one. The annotation tells LangGraph to append instead — building cumulative context across revision cycles.

from typing import TypedDict, List, Dict, Any, Annotated
import operator

class AgentState(TypedDict):
    query: str
    research_data: Annotated[List[Dict[str, Any]], operator.add]
    critic_feedback: str
    revision_count: int
    final_report: str
    is_sufficient: bool

The Critic Agent — The Key Design Decision

The Critic is what separates this system from a simple RAG pipeline. It receives the research data and asks: Is the evidence recent enough? Are there contradictions between sources? Is the population studied the right one?

async def critic_node(state: AgentState):
    prompt = f"""You are a Medical Critic. 
    Evaluate if this research is sufficient for the query.
    Query: {state['query']}
    Research Data: {state['research_data']}
    Respond ONLY with valid JSON:
    {{"is_sufficient": true, "feedback": "your feedback"}}"""

    res = llm_deepseek.invoke([HumanMessage(content=prompt)])
    parsed = json.loads(res.content.strip())

    return {
        "is_sufficient": parsed.get("is_sufficient", False),
        "critic_feedback": parsed.get("feedback", "")
    }

If the Critic returns is_sufficient: false, the graph sends the Researcher back for another round — up to 3 times maximum to prevent infinite loops.

Human-in-the-Loop

This is the most critical safety feature. Before the Writer generates the final report, the graph pauses and presents the collected evidence to the user.

clinical_app = workflow.compile(
    checkpointer=MemorySaver(),
    interrupt_before=["writer"]
)

state = await clinical_app.aget_state(config)
ans = input("Approve research and generate report? (y/n): ")

if ans == 'y':
    async for event in clinical_app.astream(None, config=config):
        if "writer" in event:
            report = event["writer"]["final_report"]

When the user types y, the graph resumes from the checkpoint using MemorySaver — no data is lost between the pause and the resume.

Real Test Query

I ran the system with this query:

“Latest evidence on semaglutide for obesity treatment in CKD patients?”

The Critic agent referenced the 2024 FLOW trial in its evaluation — the AI didn’t just search, it questioned the quality and specificity of what it found. The final report is available in the repository as clinical_report.md.

Terminal Output

🎯 Orchestrator: Iniciando pipeline...
🔬 Researcher: Rodada 1 de pesquisa...
   🔧 Usando ferramenta: tavily_search
   🔧 Usando ferramenta: pubmed_mock_search
🧐 Critic: Avaliando qualidade dos dados...
   ✅ Suficiente: True
--- Executing: __interrupt__ ---

Aprovar pesquisa e gerar relatório? (y/n): y
✍️  Writer: Gerando relatório clínico...
✅ Relatório gerado: clinical_report.md

Stack

• LangGraph — stateful multi-agent orchestration
• LangChain — LLM abstractions and tool calling
• DeepSeek — cost-efficient OpenAI-compatible LLM
• Tavily — AI-optimized real web search
• Pydantic — structured outputs
• Python 3.14

Full Repository

Complete code, architecture decisions, and the AI-generated clinical report example:

graph TD
    A([START]) --> B[🎯 Orchestrator]
    B --> C[🔬 ResearchernTavily + PubMed]
    C --> D[🧐 CriticnEvaluates quality]
    D -->|Not sufficient| C
    D -->|Approved| E{👤 Human ReviewnHITL}
    E -->|y| F[✍️ WriternMarkdown Report]
    F --> G([END])

What’s Next

• Real PubMed API integration (replace mock)
• FastAPI endpoint to serve queries via HTTP
• Weekly monitoring mode with alerts on new studies
• Multi-condition support — configurable per user
• Output variants — technical for doctors, simplified for patients

If you’re building with LangGraph or multi-agent systems, I’d love to connect. Drop a comment below or find me on LinkedIn.