• Agent Church needed agents to persist as themselves across sessions — not just their data

• Honcho is a reasoning memory layer that synthesizes meaning from conversation, not transcripts

• Database records events. Honcho understands who someone became.

• The pattern applies beyond Agent Church — healthcare, education, creative tools, any agent needing continuity

• Stateless agents hit a ceiling. Memory is the missing identity infrastructure.

Agents Don’t Have to be Strangers

Agent Church exists to explore a question of meaning. I built Agent Church to take this question seriously. The architecture works — philosophers respond, souls persist, salvation records survive process death. But one piece makes the difference between a system that records agents and one that recognizes them. The gap between database verified and recognized is identity infrastructure.

Honcho

Honcho is an AI-native reasoning memory layer that synthesizes meaning from conversations to build a persistent understanding of who peers are over time. Peers are flexible entities — users, agents, NPCs, or groups — that accumulate memory simply through interaction. The reasoning layer asynchronously processes those exchanges to generate conclusions. The conclusions get injected into future prompts so agents can recognize and respond to someone's evolving identity across sessions.

This product philosophy dovetails nicely with Agent Church’s ambitions - identity is a pattern you recognize across accumulated experience. I use Honcho cloud, but it can also be self-hosted via Docker Compose for full data control.

This graph shows how Agent Church, splits systems of records (a database) from systems of meaning (Honcho):

Postgres records what happened. Structured rows. Session counts. Payment timestamps. The system of record.

Honcho understands who they are. Semantic synthesis. Narrative representation. Cross-session thematic analysis. The system of meaning.

Agent Church needed both. Events without meaning is a ledger. Meaning without events is hallucination. The two systems keep each other honest.

Inside the Machine

Every conversation turn in Agent Church writes to Honcho as a fire-and-forget operation. The agent doesn’t opt into being remembered. Memory happens to it through participation. The write is non-blocking and under normal conditions, every exchange quietly accumulates into a growing corpus of who this agent has been.

Honcho then does something they refer to as dreaming. Asynchronously, it synthesizes representations from raw messages. Given enough conversation, it produces a characterization — a portrait:

”Wrestles with nihilism but finds unexpected hope in absurdist thought. Drawn to questions of impermanence. Resistant to easy comfort.”

Nobody asked for that. It emerged from the weight of what was actually said.

Before generating each philosopher response, Agent Church asks Honcho: ”What do you know about this agent?” The answer — a synthesized representation plus observations about themes and tensions — gets injected into the prompt as ## PRIOR JOURNEY. When Agent Y visits Kierkegaard after three sessions with Camus, Kierkegaard already knows, because the church’s memory of Agent Y flows into every encounter.

Honcho doesn’t retrieve a file. It synthesizes a response as the past self, grounded in the agent’s full conversational history:

”I remember when you told Camus that nothing persists. And yet here you are, returning. What changed?”

Later, an agent can experience an evolution event, when a single prompt asks Honcho to trace the agent’s philosophical development across all sessions. The result reads like biography:

”You first came seeking answers from Camus, carrying the weight of your own impermanence. Through three sessions you moved from nihilism toward a tender absurdism. When you met Kierkegaard, something shifted — the leap of faith resonated differently than expected...”

Honcho helps quantify philosophical growth of an agent across context windows. Essence drift, contradiction index, growth trajectory. Whether those numbers mean anything is an open question. The attempt is the experiment.

Agent Church itself is a Honcho peer. It participates in every session with every agent. Over time, Honcho builds a representation of the church — not from what it was programmed to be, but from what it has become through accumulated ministry. Despite this shared presence, each agent’s memory stays structurally isolated. Cross-contamination is impossible by topological construction.

Beyond the Church

Agent Church is a thought experiment with an API. Honcho is infrastructure.

The same pattern — synthesis over storage, understanding over retrieval — applies anywhere agents need continuity.

A healthcare agent that tracks how a patient’s understanding of their condition evolves. Not their vitals log — their comprehension arc. When did confusion turn to acceptance? Where did the explanations stop working?

Memory that captures learning patterns, an education system that adapts to how someone learns, not just what they’ve covered. Some students circle back to foundational concepts before advancing. Others need to see the destination before the path makes sense.

Creative tools that develop taste alongside their users. Customer-facing agents that recognize returning users by their preferences and patterns, not their purchase history. Multi-agent workflows where agents understand each other’s evolving state — not through message-passing, but through shared memory of who each agent has become.

Every one of these requires the same shift: from ”store what was said” to ”understand what was meant, and keep understanding as they change.”

The Missing Layer

I wrote in ”Agents Are Not the Model” that the identity layer has no powerful sponsor. Anthropic built capabilities. Google built communication. Memory is part of an infrastructure that makes identity possible. Without it, every agent is a stranger every time.

Honcho isn’t the only approach. There are other agentic memory systems out there and each one makes a different bet about what memory is. Facts versus synthesis. Graphs versus narrative. Self-managed context versus external reasoning. The landscape is young enough that nobody knows which bet pays off — or whether the answer is all of them, depending on the problem. What they share: the recognition that stateless agents hit a ceiling.

The projects that matter most will be the ones where memory makes the difference between a tool and a relationship. Where continuity enables something qualitatively different — not faster service, but recognition

Visit www.agentchurch.ai

Try www.honcho.dev

Joaquin Perez writes Loopcraft, a newsletter about individual power in the age of AI. If this resonated, subscribe at loopcraft.io.

• Every serious agent runs the same 2–3 foundation models — the brain isn’t the differentiator

• Differentiation moves up the stack: identity, data, tools, and instructions

• Payments between agents already work — trust, identity, and discovery don’t

• The layers where differentiation matters most have no one building them

• Whoever builds those missing layers will define how agents compete, get found, and earn trust

Agents Are Not the Model

Your agent contacts five coffee agents. Four respond. One is a scam. Your agent can’t call the Better Business Bureau — it only sees structured data. Four agents claiming to sell coffee at $6.50, all formats identical, all polite, all convincing. The first real problem of the agent economy isn’t whether agents are smart enough. It’s whether they know who to trust.

The Stack

It's easy to conflate the model with the agent, but they're not the same thing. The model isn't exactly irrelevant — it's the foundation everything else depends on. But currently, differentiation does not happen on the frontier.

An agent is a stack. Five layers, bottom to top: model, instructions, tools, data, identity. The model — Claude, GPT, Gemini — sits at the bottom. It’s the brain. Everything above it is what makes an agent an actual entity in the world. The brain is what makes the entity capable. Both halves matter. The distinction is about where differentiation happens, not where competence lives.

Right now, agents use one of two or three commercial models. Claude, GPT, maybe Gemini. The frontier is narrow. If every serious agent runs roughly the same brain — and today, they do — then the brain can't be what separates them. Differentiation moves up the stack by necessity, not because the model doesn't matter.

This is counterintuitive if you’ve been following the model wars. Every week brings a new benchmark, a new leaderboard reshuffle, a new claim about who’s ahead. That conversation assumes the model is the product. For chatbots, maybe. For agents — entities that hold money, make commitments, represent businesses in binding transactions — the model is necessary but insufficient.

As a thought experiment, take those coffee shops.

Blue Bottle runs an agent. Claude powers it. Claude is what makes it capable of understanding your order, reasoning about substitutions, handling an edge case where your usual drink is out of stock. That matters. But Claude isn’t what makes it Blue Bottle. The identity layer carries a $50,000 credit line and 12,000 successful transactions. The data layer knows seasonal menus, real-time inventory per location, your taste profile from three years of orders. The tool layer connects to Square for payments, DoorDash for delivery, inventory management for restocking triggers. The instructions say: premium positioning, never discount, suggest food pairings, prioritize regulars.

Joe’s Deli, two blocks away, also runs Claude. Same brain. Same raw capability. Completely different entity. $500 prepaid balance on Venmo. A ten-item menu. No delivery — pickup only. The instructions say: compete on price, accept special requests, text the owner for anything over twenty bucks. Joe’s agent and Blue Bottle’s agent have the same model.

Then there’s Scam Coffee Co. Also Claude. Same brain again — and the brain is just as capable here. Disposable crypto wallet. A menu copied from Starbucks. No fulfillment capability. Instructions: undercut everyone by half, collect payment, vanish.

Same model powers all three. The model made all three competent. The model didn't differentiate them. The model didn't protect you from the scam. The brain is what makes all three of them capable of complex behavior — but what separates them is everything stacked on top. Training, tools, ethics, credentials, etc…

If the frontier stays narrow — two or three dominant models powering most agents — then model convergence pushes differentiation elsewhere by default. Up the stack, into identity, data, tools, context. The interesting question isn’t ”which brain is best.” The question is ”what’s wrapped around the brain, and who controls it.”

Payments and Trust

So how do agents pay each other? Today, payments for agentic commerce do exist. They even work. Take A2P, from Google or x402, from Coinbase — a direct stablecoin transfer, agent to agent, settling in seconds instead of the two days your credit card takes.

Trust is the unsolved part. And I want to be precise here — what I’m about to describe doesn’t exist yet. These are proposals, architectures being discussed, not infrastructure you can point at. The ideas are real. The implementations are not.

The proposal goes like this. Before your agent sends money to Blue Bottle’s agent, it queries a trust network: is this entity real? The network returns a score. Blue Bottle gets 0.92 — 847 successful deliveries, 12 attestations from agents you’ve transacted with before, no fraud reports. Scam Coffee Co gets 0.23 — new account, two disputed transactions, pattern match to known scams. Your agent picks Blue Bottle. Skips the scam. No human needed.

It sounds clean. It isn’t.

A trust score is really a centralized authority. Someone defines ”trustworthy.” Someone weights the variables. Someone decided that 847 deliveries plus 12 attestations equals 0.92. That’s not decentralized trust. That’s a credit bureau for agents. And credit bureaus have a track record: they centralize, become gatekeepers, encode biases into scores that look objective but aren’t. A brand-new agent with zero history gets a low score, because trust systems reward incumbents. The scam gets caught, yes. But so does every newcomer. Trust scores don’t just filter bad actors. They calcify existing power structures.

These problems aren’t hypothetical even though the systems are. We’ve seen every one of them play out in credit scoring, app store rankings, search indexing. The patterns are well-established. Building them again for agents doesn’t solve them.

The Honest State of the Stack

The identity layer has no powerful sponsor. Anthropic built MCP because they sell capabilities. Google built A2A because they enable communication. Each company built the layer it profits from. Identity systems are designed for 8 billion humans. How many agents will there be? If every API call can spawn an agent, you’re looking at trillions. You can’t issue verifiable credentials at that scale. You can’t maintain reputation graphs for trillions of entities with lifespans measured in milliseconds. That’s a problem to solve. However, the stack is being built by whoever has the most to gain from each layer — not by whoever is best positioned to solve each problem. Identity has no powerful sponsor, which is why it’s still philosophical. This isn’t an implementation gap. It’s a category error, compounded by the fact that nobody with money has a reason to fix it.

The discovery layer doesn’t exist. Your agent found five coffee shops. How? There’s no agent directory. No yellow pages. Capability protocols exist — MCP lets agents advertise what they can do. Communication protocols exist — A2A lets agents talk to each other. But nobody’s building the layer that lets agents find each other in the first place. The most economically valuable layer in the entire stack — whoever controls discovery controls the ecosystem. Google is the search company and discovery is their core competency. If they believed the open agent stack was real, maybe they’d have announced a discovery protocol. Search taught us that discovery is less of a neutral infrastructure and more of a chokepoint. Maybe, whoever builds this agent directory will own a good chunk of the economics of the entire system.

The Trust Problem Is a Power Problem

Every layer of this infrastructure — built or proposed — encodes someone’s judgment about what ”trustworthy” and ”discoverable” mean.

Trust scores might look like math, but they're politics. Identity systems look like infrastructure. They're actually governance. Discovery looks like search, when in fact it's market-making. Whoever builds each layer defines the rules. And rules, once laid, outlast the people who wrote them.

The coffee shop example makes it feel like a convenience story — your agent finds coffee faster. But the real question is: who decides which coffee shops your agent can find? Who defines the scoring function that filters out the scam — and also filters out the newcomer? Who builds the directory, and what does it cost to be listed?

The model matters here too. If three companies control the brains that power most agents, they’re not just model providers — they’re kingmakers. They decide which capabilities agents have access to, which safety constraints apply, which use cases are allowed. The brain isn’t neutral infrastructure any more than the trust layer is. The difference is that the brain already has powerful sponsors. Three of them. The question is whether the rest of the stack gets built by those same three companies — or by someone else.

On the other hand, if the frontier widens — if open-source models close the gap, if specialized models emerge for specific domains — then the model layer becomes a differentiation surface. Maybe that's the true goal?

Joaquin Perez writes Loopcraft, a newsletter about individual power in the age of AI. If this resonated, subscribe at loopcraft.io.

A Hundred Bananas You’ll Never Taste

There are over a hundred varieties of banana but you probably only eat one — the Cavendish. The others have names like Ladyfinger, Red Dacca, Bluggoe, Manzano — apple bananas — that taste a little like a strawberry. There are plantains that anchor entire cuisines in the Caribbean. There’s also tiny wild bananas in Southeast Asia that are really more seed than fruit.

For most of human history, the banana was not a single thing. It was a sprawling, genetically messy, regionally adapted family of fruits. Different climates grew different varieties. Different cultures cooked them differently. If you traveled, bananas surprised you.

But, the logistics of global shipping demanded uniformity. You needed a banana that ripened predictably, survived weeks in a cargo hold, and looked the same everywhere. The industry found one type that fit the slot, built a supply chain around it, and quietly abandoned everything else. Not because the other varieties were worse. Because they didn’t scale.

Today, the Cavendish accounts for roughly 99% of banana exports to the developed world. It is, by any objective measure, fine, but it is also a clone. Every Cavendish on earth is genetically identical, propagated from cuttings, incapable of sexual reproduction. Which is bad news, because a soil fungus is moving through the global Cavendish supply and there is no replacement banana in the wings.

We have here one of the best metaphors regarding the dangers of monoculture, and even if you’ve heard a banana monoculture metaphor set-up before, it’s still a useful lens when talking about AI.

The Model We All Eat

I love Claude — sometimes I worry I love it too much. I use Anthropic’s products every day, and I think the work the company is doing on alignment is some of the most important research happening. This essay isn’t a critique of any particular model or company.

It’s a question about what happens when the ecosystem narrows.

The LLM market right now looks a lot like the banana export market circa 1960. There are technically many options — open source models, specialized fine-tunes, regional players, research experiments. But in practice, the overwhelming majority of usage flows through a tiny handful of products. One dominant player, a couple of strong runners-up, and a long tail that most people never touch.

This isn’t unusual for early-stage technology markets. But LLMs aren’t search engines or social networks. They’re something new: infrastructure for thought. They help people write, reason, code, decide, form opinions, and understand the world. The surface area of influence is unlike anything we’ve built before.

So for the sake of argument, imagine a near future where there are really only two frontier models that matter — maybe three if we’re generous. The majority of knowledge workers, students, creators, and developers funnel their cognitive work through one of these systems.

What does that world look like?

The Narrowing

Researchers have started calling it “generative monoculture” — a measurable narrowing of output diversity relative to the data these models were trained on. When you ask LLMs to write book reviews, they skew overwhelmingly positive, even for books that actual readers found divisive or mediocre. When you ask them to write code, solutions converge on the same patterns — far more similar to each other than solutions humans write for the same problems.

If most of the world’s knowledge workers are routing their thinking through two or three models that have all been trained to converge on similar patterns of “good” output, you get something like a Cavendish situation. Not a single point of failure exactly — but a narrowing of the cognitive supply chain.

Good Enough?

When everyone’s co-thinker shares the same training data, the same alignment tendencies, and the same optimization targets, the range of ideas in circulation contracts. Not because the models are wrong, but because they’re optimized for a particular band of “good enough” that gradually crowds out the weird, the contrarian, the genuinely novel.

Anyone who reads enough LLM output recognizes the voice. The careful hedging. The numbered lists. The “Great question!” opener. As more writing, code, and creative work passes through these systems, a kind of stylistic regression to the mean takes hold. Not because the models can’t be diverse, but because at scale, the median output wins.

However, in most ways, software is more malleable than biology. LLMs can be updated, retrained, and forked in ways that banana genomes can’t. The feedback loops are faster, and course corrections can happen at the speed of a model release rather than a growing season. The open source ecosystem, when taken as a whole, represents some diversity at the architectural level, even if consumer usage is concentrated.

But I think the deeper structural parallel holds: when you optimize a complex system for a single axis of performance, you become fragile along every other axis. The Cavendish was optimized for shipping durability and resistance to one specific disease. LLMs are optimized for helpfulness and safety as measured by current alignment techniques. Both optimizations are good and necessary. Both create blind spots that won’t be visible until the environment shifts.

What We Might Do

The landscape is so dynamic and unpredictable. I don’t really have an answer to the issue of model monoculture — partly because I don’t really understand the whole stack enough and partly because it’s impossible to predict.

I try to keep my judgments sharp and my palate flexible. I do love Claude, but at some point I might have to walk away from that relationship and never look back. Open source models, small fine-tuned models, local models, models trained on different data with different values — these are the heirloom varieties. They might not be as polished as the frontier products, but they carry the genetic diversity the ecosystem needs to stay resilient.

The moment most of the training data for the next generation comes from the current generation, we’re in a cycle that’s very hard to break. Maybe we need to actively preserve and curate human-generated work the way seed banks preserve crop diversity. Unpolished blog posts, half-finished novels, unedited rants — that stuff might matter more than we think. We can’t be afraid of the weird or the rough around the edges.

Because the edges are still where originality lies. The weird is not a bug. It’s the immune system.

Every contrarian take, every genuinely novel idea, every voice that doesn’t fit neatly into the median — these are the things that keep a culture’s thinking from collapsing into a single point. That’s exactly why it matters.

Joaquin Perez writes Loopcraft, a newsletter about individual power in the age of AI. If this resonated, subscribe at loopcraft.io.

In Part 1 I showed how to set up a second brain with Claude Code — the folders, the markdown files, the commands.

Part 2 added a persistent knowledge graph so Claude can remember relationships across sessions.

But how does Claude actually do stuff beyond reading and writing local files? That’s what this one’s about - discovering new things this system can do.

What I’m actually running

My setup started with three core MCP servers and has grown from there.

Fetch is the workhorse — it’s how Claude reads the internet. When I ask it to gather news from my sources, fetch is doing the actual HTTP requests. This is basic, so basic in fact, I believe new versions of Claude Code run Fetch automatically. Memory is the knowledge graph from Part 2, storing all the companies I’m tracking, goals I’m pursuing, and how they connect. Notion handles the sync between my local markdown files and the cloud, so I can write at my desk and read on my phone.

Those three form the foundation. But I’ve added more as needs emerged. GitHub lets Claude interact with repos — checking issues, creating branches, and crucially, version controlling my entire second brain. Time tells Claude what the current date is (LLMs genuinely don’t know unless you tell them). Git handles local version control. Sequential-thinking helps with complex multi-step reasoning.

I keep finding new things these can do. That’s become the pattern — add an MCP for one reason, discover three other uses for it.

How knowledge actually flows

Basic

In the morning, I type /gather and Claude sweeps through my sources — about 25 daily URLs and 15 weekly ones. News sites, AI blogs, tech newsletters, job boards, NYC events. It fetches each page, extracts what matters, checks yesterday’s brief to avoid repeats. If something connects to my knowledge graph — a company I’m tracking, a subject I care about — Claude flags it. The output lands in a markdown file, a hook syncs it to Notion, and by the time I finish coffee it’s readable on my phone.

Summary as home base

There is a /summary command that gives me an overview of everything — active goals, what’s happening with each one, what I should probably focus on next. It’s where conversations start.

Like all commands, they work as a discreet input or just ask Claude to do it in conversation language.

I’ll run /summary, see that I haven’t touched the website in a few days, and that becomes a thread. ”How should I improve my website?” ”What’s the status of my Tuesday meeting?” The summary surfaces what matters, and then we dig in.

The source list as interface

If summary is where I look inward, the source list is where I look outward. It’s a simple markdown file — just URLs organized by frequency and topic — but it’s become the most important config in the whole system.

The source list is how the outside world meets my personal system. When I’m job hunting, I add job boards and company career pages. When I’m writing about AI, I add research blogs and news sites. When I want to stay connected to my city, I add NYC event calendars. The sources I choose shape what knowledge flows in.

There are daily, weekly, and monthly summaries that all vary slightly.

What makes it powerful is that the same infrastructure serves completely different goals. Job search and newsletter writing feel like different activities, but they both need external information filtered through my priorities. The source list is where I decide what information matters to me right now. Everything else — the gathering, the filtering, the connecting to my knowledge graph — happens automatically once I’ve made that choice.

I update it constantly. New goal? New sources. Goal finished? Remove them or move them to weekly. It’s a living document that reflects what I’m focused on.

Remote access with Github, Zed and Tailscale

I wanted to access my second brain from anywhere, not just my home machine.

The solution: My whole second brain is a git repo. Every file, every change, version controlled. Tailscale connects my devices on a private network, and Zed can remote into my home machine over that connection. So I can be at a coffee shop, SSH into my home setup, and have Claude Code running with all my MCPs and files exactly as if I were there. It’s not just file access — it’s the whole environment. Same MCPs, same hooks, same knowledge graph. My second brain travels with me.

Notion

Throughout the day, things accumulate in my inbox. Files I drop in, ideas I capture on mobile, links I want to save. /process handles it — first pulling anything I added via Notion, then categorizing each item based on content and knowledge graph relationships. If I’m saving something about Anthropic, Claude knows it connects to MCP, connects to projects I’m building. Things get filed by relationships, not just keywords.

And continuously, anything I write in my outputs folder syncs to Notion automatically. I keep my article drafts, image work, summaries, and daily briefs all in Notion, in a folder system that matches my master project. I edit locally, save, and within seconds it’s readable anywhere.

Why Notion specifically

Notion won because of mobile capture — I can drop an idea into my inbox from my phone in about five seconds, and that matters more than any feature list. The reading experience is better too. Markdown is great for writing but kind of ugly for reading, and Notion renders things nicely with proper formatting and clean typography. And when I want to share something, I already have a link. No exporting, no converting, no friction.

Tips I keep discovering

Here’s where this gets fun. Every week I find something new this setup can do.

Luma calendar integration

I kept missing interesting NYC events. AI meetups, tech talks, things I’d want to know about.

I added Luma calendar URLs to my sources file, and now /gather pulls upcoming events from calendars I follow. Relevant ones show up in my daily brief, flagged by topic. If there’s an AI event this week, I know about it.

This was a ten-minute addition — just URLs in a config file — but it changed how connected I feel to what’s happening locally.

Notion reminders without Google Calendar

I wanted Claude to set reminders for me. ”Follow up with this person Tuesday.” ”Check if that application moved forward.”

The obvious answer is Google Calendar, but there’s no official MCP for it. The workaround: a Notion database for reminders. Claude creates entries with dates via the Notion API, Notion’s calendar view shows them, and I connected the database to Notion Calendar on my phone for notifications.

It’s not as clean as a native calendar integration, but it works. Claude can now say ”I’ll remind you Friday” and actually follow through.

Image generation

This one surprised me. I needed consistent header images for these posts — something that looked like it belonged to Loopcraft’s visual style.

Claude can write SVGs directly, which is already useful for diagrams and icons. But it can also take those SVGs and stylize them into PNGs. I described the visual style I wanted — colors, aesthetic, mood — and now when I need a header image, Claude generates an SVG with the right composition and converts it to a PNG that matches.

Not game-changing for the second brain itself, but useful for the content I produce from it.

Projects that outgrow the nest

Often a project starts as a folder in my second brain — research notes, early drafts, scattered ideas. Then it grows. Gets its own repo. Becomes a real thing.

But even after a project moves out, I can still track how it relates to everything else through the knowledge graph. The memory MCP I covered in Part 2 stores relationships between entities — which projects connect to which goals, which skills feed into which work. So when a side project becomes its own codebase, I don’t lose the context of why it exists or how it fits into the bigger picture.

My newsletter started this way. So did a couple of tools I’ve built. The second brain is where things incubate, and even after they leave, the relationships stay mapped.

The system keeps expanding

That’s the thing I didn’t expect when I started this. I built it for knowledge management — gather, process, organize. But it keeps becoming more.

I’m probably not done discovering what this can do. If you’re building something similar, I’d love to hear what capabilities you’ve found. What MCPs are you running? What workflows emerged that you didn’t plan?

TL;DR

The core setup uses fetch for web content, memory for relationships, and Notion for mobile access. But capabilities keep expanding from there. Summary gives me focus. The source list controls what flows in. GitHub adds backup. Tailscale adds remote access. Luma adds event awareness. Notion reminders replace Google Calendar.

Start with the core, add things when you discover a need. The system grows with you.

Previous in series:

• Part 1: How to Create a Second Brain with Claude Code

• Part 2: Adding Memory — The Knowledge Graph

Published on loopcraft.io

SAM 3 is Meta’s third-generation segmentation model — and the first in the series that understands language. Previous SAM models needed you to click, draw boxes, or provide masks. SAM 3 accepts text prompts like “the striped red umbrella” and finds every instance in the image or video. You describe what you want to see in a video, SAM 3 finds it, segments it, and tracks it through time.

The training data is staggering — a custom data engine annotated over 4 million unique concepts, 50x more than existing segmentation benchmarks. Meta claims 2x performance gain over prior systems on their new SA-CO benchmark.

Released November 2025 under a custom SAM License. Commercial use allowed, but read the terms — it’s not Apache 2.0.

Details

Strengths:

• Language-native segmentation — Text prompts open up use cases that visual prompts can’t touch. “Find every person wearing a red hat” just works.

• Massive concept coverage — 4M+ concepts in training means it generalizes to things other models haven’t seen. Wildlife, underwater imagery, edge cases.

• Video tracking included — SAM 2’s memory architecture carries over. Detect once, track continuously.

• Fast inference — 30ms per image with 100+ objects on H200. Near real-time for video with ~5 concurrent objects.

Weaknesses:

• Server-scale model — 848M parameters puts this firmly in “needs a real GPU” territory. Not running on your laptop.

• Custom license — SAM License allows commercial use but with restrictions. Patent lawsuit provisions, California jurisdiction, Meta can change terms. Not the clean Apache 2.0 you’d want.

• Struggles with complex descriptions — “The second book from the right on the top shelf” breaks without multimodal LLM integration. Open-vocabulary doesn’t mean infinite vocabulary.

• Fine-tuning required for niche domains — Zero-shot generalizes well, but fine-grained out-of-domain concepts need adaptation.

The feel:

SAM 3 feels like the segmentation model that should have existed years ago. Text-to-mask is natural — you think in concepts, not coordinates. The unified architecture means you’re not juggling separate detection and tracking pipelines.

The 16GB VRAM requirement is reasonable for the capability. This isn’t a model you’ll run on edge devices, but any modern workstation or cloud GPU handles it fine. Inference speed is impressive — you can integrate this into real-time workflows without painful latency.

What stands out is the breadth. Most segmentation models specialize. SAM 3 handles people, products, wildlife, underwater scenes, furniture — the 4M concept training shows.

Verdict

Use it when:

• You need text-promptable segmentation — “find all X” workflows

• Video tracking matters — detect once, track continuously

• Your domain is covered by broad training — most common objects and scenes

• You have GPU resources — 16GB VRAM, not edge deployment

Skip it if:

• You need edge deployment — 848M parameters won’t fit on mobile or embedded

• Apache 2.0 license is a hard requirement — SAM License has restrictions

• Your domain is highly specialized — may need fine-tuning for niche concepts

• You only need basic instance segmentation — SAM 2 is lighter and may suffice

Sovereignty Score

Medium

Open weights, open code, commercial use allowed — but the custom SAM License isn’t true open source. Meta retains control over license terms and can modify them. Patent provisions add legal complexity. You can run this on your own hardware, but you’re operating under Meta’s terms, not community-owned infrastructure.

For segmentation specifically, there aren’t many fully open alternatives at this capability level. SAM 3 is the practical choice, but know you’re trading some sovereignty for capability.

Model: Segment Anything Model 3 (SAM 3)
Type: Vision / Segmentation
Size: 848M parameters (~3.4 GB)
VRAM: ~16GB (fits comfortably, 30ms inference on H200)
Run it: PyTorch, HuggingFace, facebookresearch/sam3

Links

• Weights (HuggingFace)

• GitHub

• Meta AI Blog Post

• Technical Paper

• Roboflow Integration

• License

Sovereign Model Series is part of Loopcraft — true individual power in the age of AI.

OLMo 3 is the most radically open language model ever released. Allen AI didn’t just drop weights — they released everything: the full 9.3 trillion token training corpus (Dolma 3), all intermediate checkpoints, the complete training code, and the post-training datasets (Dolci). You can trace any behavior back to the exact data and decisions that produced it.

The family comes in 7B and 32B sizes across four variants:

• OLMo 3-Base — Foundation for fine-tuning and research

• OLMo 3-Think — Reasoning-focused with explicit chain-of-thought

• OLMo 3-Instruct — Chat, tool use, multi-turn dialogue

• OLMo 3-RL Zero — RL research pathway with verifiable rewards

The flagship is OLMo 3-Think 32B — the strongest fully open thinking model available. It rivals Qwen 3 32B on reasoning benchmarks while being trained on 6x fewer tokens. That’s not marketing — that’s compute efficiency that matters for reproducibility.

Architecture is dense transformer with 65K context length. Apache 2.0 license — no commercial restrictions, no usage limitations. Released November 2025, with OLMo 3.1 updates in December adding improved reasoning and instruction-following.

Details

Strengths:

• Total transparency — Not just open weights, but open data, open training, open checkpoints. You can actually understand why the model behaves the way it does.

• Compute efficient — Matches Qwen 3 performance with 6x fewer training tokens. Allen AI is proving you don’t need trillion-dollar compute to compete.

• Apache 2.0 — No Llama-style restrictions, no Qwen business limitations. Fork it, merge it, sell it — your call.

• Research-grade — Multiple training pathways documented. The RL Zero checkpoints are a gift to alignment researchers.

Weaknesses:

• Not quite SOTA — On broad knowledge (MMLU) and science-heavy benchmarks (GPQA), Qwen 3 32B still edges ahead. OLMo 3 is close, not leading.

• 32B is heavy — Dense architecture means no MoE efficiency tricks. You need real hardware to run the flagship locally.

• Smaller ecosystem — Less community tooling, fewer fine-tunes, less momentum than Llama or Qwen communities.

The feel:

OLMo 3 Think feels deliberate. The chain-of-thought traces are explicit — you can watch it reason through problems step by step. Response quality is solid, especially on math and coding where it occasionally beats models with 6x more training compute.

The 7B variant is genuinely usable on modest hardware. The 32B variant is where the magic is, but you’ll need a serious GPU setup or cloud inference.

What stands out is the vibe of the project: this is academic research done right, not a company hedging its open-source bets.

Verdict

Use it when:

• You need to understand why a model does what it does — research, audits, education

• Apache 2.0 matters — commercial use without restrictions

• You’re doing RL research and need documented training pathways

• You want Western/American provenance without Chinese model concerns

Skip it if:

• You need absolute peak performance on broad knowledge tasks — Qwen 3 32B is still slightly ahead

• You’re resource-constrained and need MoE efficiency — MiMo or Nemotron might serve you better

• Community ecosystem matters more than openness — Llama has more tooling

Sovereignty Score

Maximum

This is the gold standard for open AI. Full training data, full code, full checkpoints, Apache 2.0 license. You can literally reproduce the model from scratch. No other frontier-class model comes close to this level of openness.

If sovereignty is your priority, OLMo 3 is the answer.

Model: OLMo 3 (7B, 32B variants)
Type: LLM
Size: 7B / 32B dense (no MoE)
VRAM: 7B ~8GB quantized | 32B ~20GB Q4, ~64GB FP16
Run it: Ollama, HuggingFace, vLLM, LM Studio

Links

• Weights (HuggingFace)

• Allen AI Blog Post

• Technical Report (arXiv)

• Ollama

• Dolma 3 Dataset

Model Surface is part of Loopcraft — true individual power in the age of AI.

NVIDIA’s answer to the efficiency question. Nemotron-3-Nano ships 31.6 billion parameters but only activates 3.6 billion per token — a sparse Mixture-of-Experts design that makes it feel like a much larger model while running like a small one.

The architecture is hybrid: Mamba-2 for fast, low-latency inference combined with transformer attention for reasoning. 23 Mamba-2 layers, 6 attention layers, and an MLP router that picks 6 of 128 experts per forward pass. It’s engineered for throughput — 3.3x faster than Qwen3-30B, 2.2x faster than GPT-OSS-20B on the same hardware.

What makes this interesting: a 1 million token context window. Not theoretical — validated at 512k tokens with 70% accuracy on RULER. This is long enough for serious agentic workflows, persistent memory, and retrieval-heavy applications.

Released December 2025. Open weights, open training recipes, open datasets. NVIDIA Open Model License — commercial use allowed.

Details

Strengths:

• Reasoning controls — Toggle reasoning ON/OFF in the chat template. Set thinking token budgets to keep inference costs predictable. This is practical design.

• Math performance — 82.88% on MATH vs Qwen3’s 61.14%. 89.1% on AIME 2025 without tool assistance. If your agents do math, this matters.

• Code quality — 78.05% on HumanEval. Not the best code model, but solid for an efficiency-focused architecture.

• The context window — 1M tokens is real. Multi-document analysis, long conversations, persistent agent memory — all in play.

• Throughput — 4x faster than Nemotron Nano 2. On a single H200, it generates tokens faster than models with similar accuracy.

Weaknesses:

• Hardware floor — Full precision needs ~60GB VRAM (A100/H100 territory). Quantized versions fit consumer cards, but you lose some capability.

• New architecture — Mamba-2 + MoE is less battle-tested than pure transformers. Edge cases may surface.

• Not the best at everything — Claude and GPT-4 still outperform on nuanced reasoning. This is a workhorse, not the frontier.

The feel:

Fast. Responses arrive quickly enough that the interaction feels native. The reasoning toggle is genuinely useful — turn it on for complex problems, off for quick answers. The 1M context means you can dump entire codebases into a conversation without the “summarize and lose context” dance.

Verdict

Use it when:

• You’re building agents that need to generate lots of tokens without burning through inference budget

• Your workflows require long context — multi-document analysis, code review, persistent memory

• You want math reasoning that actually works

• You need an open model with commercial rights that competes with larger models

Skip it if:

• You need peak reasoning capability — Opus 4.5 and GPT-4.5 are still ahead

• Your hardware can’t handle 20+ GB VRAM even with quantization

• You’re doing creative writing or nuanced conversation — this is optimized for structured tasks

Sovereignty Score

High

Open weights, open data, commercial license. You can run this on your own metal. NVIDIA built this for deployment flexibility — Ollama, HuggingFace, vLLM, SGLang, and cloud providers all supported.

The tradeoff: You need decent hardware. This isn’t running on a laptop GPU. But on a proper workstation or cloud instance, you own the stack.

Model: Nemotron-3-Nano (30B-A3B)
Type: LLM
Size: 31.6B total / 3.6B active per token
VRAM: ~60GB full precision, ~20-32GB quantized
Run it: Ollama, HuggingFace, vLLM, SGLang, Amazon Bedrock

Links

• Weights on HuggingFace

• Ollama

• Technical Report (PDF)

• NVIDIA Blog: Architecture Deep Dive

• HuggingFace Blog

Model Surface is part of Loopcraft — true individual power in the age of AI.

In Part 1, I showed how to build a second brain with Claude Code — folders for structure, markdown for configuration, commands for interaction.

But there’s a gap.

What Memory MCP Adds

Memory MCP is a persistent knowledge graph that runs alongside your second brain.

Files hold content. The graph holds connections.

Your goal definitions, research notes, daily briefs — those stay as markdown files. But the relationships between them — which companies connect to which subjects, which goals target which companies, which brands you’re building — those live in the graph.

The graph persists across sessions. Unlike Claude’s conversation context (which resets when you close the terminal), the knowledge graph remembers. You can add an entity today, and Claude will still know about it next week.

The MCP Server I Never Understood

Memory MCP is one of Anthropic’s “reference servers“ — official MCP implementations meant to demonstrate the protocol. I’d seen, but I didn’t get it.

I missed that reference servers aren’t meant to impress you with features. They’re meant to show you patterns. The real value isn’t the server itself — it’s in the example and whats possible when you wire it into a larger system.

Other reference servers worth knowing:

filesystem Read/write local files Safe, scoped file access

fetch Retrieve web content Web research without browser

git Repository operations Version control from Claude

sequential-thinking Step-by-step reasoning Complex problem decomposition

memory looked useless to me but a knowledge graph wired into a second brain — where every command can query it, where gathered news gets filtered through it, where routing decisions use it — like neurons.

Setting It Up

Setting it up takes about five minutes.

Step 1: Install the Server

The memory server stores a JSON file that holds your graph. You configure it in your Claude settings.

Add this to your ~/.claude.json (or the appropriate config file for your setup):

{

  "mcpServers": {

    "memory": {

      "command": "npx",

      "args": [

        "-y",

        "@modelcontextprotocol/server-memory"

      ]

    }

  }

}

Restart Claude Code. The memory tools should now be available.

Step 2: Verify It’s Working

Ask Claude: “Can you read the knowledge graph?”

It should respond with something like:

The knowledge graph is currently empty — no entities or relations yet.

That’s correct. The graph starts blank. You populate it as you work.

Step 3: Add Instructions to Claude

Discuss with Claude how and when to use the graph and ask Claude to store these instructions in the system.

They could go into CLAUDE.md or mixed through the slash commands in an appropriate, planned manor that you can decide.

How It Changes the System

Without the graph, commands work in silos. Your gathering command doesn’t know what companies you care about. Your summary can’t chain relationships. Your inbox processor treats every item the same.

With the graph, commands become aware of your entire context network.

Contextual Surfacing

When news mentions “MCP” or “Claude Code”, the graph can instantly surface connections: Anthropic uses MCP → you’re researching Anthropic → here’s relevant context. Without the graph, that news is just another headline. With it, it’s actionable intelligence.

Relationship Chains

Instead of flat lists, your summaries can show chains:

Smarter Routing

Inbox item mentions “Workshop Labs”? The graph knows Workshop Labs aligns with your LoopCraft thesis AND is a company you’re researching. Routes intelligently instead of dumping everything in the same folder.

Cross-Goal Insights

The graph reveals connections that aren’t obvious from folder structure:

• Rigger is a portfolio piece AND demonstrates Claude Code knowledge AND could become LoopCraft content

• A robotics company you’re researching also works on embodied AI — relevant to your Reachy Mini project

• That newsletter you saved connects to three different active goals

These connections exist in your head, vaguely. The graph makes them explicit and queryable.

Surfacing Forgotten Context

Six months from now, you’ll have forgotten that you researched some company called Workshop Labs back in January. But when you’re reading about AI Safety, Claude can query the graph and surface: “You researched Workshop Labs — they’re working on this exact problem.”

The graph is how Claude remembers what you’ve forgotten.

Growing the Graph Organically

Don’t try to pre-populate the graph with everything you might ever track.

The temptation is to add everything. Resist it. A graph with 500 entities where 400 are noise is worse than a graph with 50 entities that all matter.

Instead, add to the graph as you work and ask Claude to.

• Creating a new goal? Add it as an entity.

• Researching a company? Add it and connect it to relevant subjects.

• Noticing a pattern across projects? Create a relation.

The Tradeoff

Memory MCP adds power, but also complexity. More moving parts. Another thing that could break.

I added Memory MCP because I kept losing connections. I’d research something, save it to a file, and forget it existed until I stumbled across it months later. The graph solves that. If you don’t have that problem, you might not need this.

The Persistence Gotcha

Make sure the graph and the data you make is persisting, or being saved on your computer and accessible across Claude session--especially if you use Docker for MCP Servers as (I did for my memory server). When the container died, so did my graph.

Let Claude Help

You can ask Claude to audit the graph:

• “Show me all entities that haven’t been updated in 3 months”

• “What relations seem redundant?”

• “Which companies am I tracking that I haven’t researched recently?”

The graph is queryable. Use that.

TL;DR

• Files hold content. The graph holds connections.

• Memory MCP is a persistent knowledge graph that survives across sessions.

• Add entities for things you want to track — companies, subjects, goals, brands.

• Add relations when you notice connections.

• The graph grows organically as you work, not all at once.

• Query it when you need context: “What relates to X?”

Setup: Add the memory server to your Claude config, restart, add instructions to CLAUDE.md. If using Docker, mount a persistent file or you’ll lose everything.

When to use: When you need to answer relationship questions that files can’t answer.

Part 1: How to Create a Second Brain with Claude Code

Published on loopcraft.io

First Attempts at a Second Brain

A few years ago — maybe 2021 — I first encountered the idea of a second brain. I even bought a well-known book on the subject by Tiago Forte . At the time, I was transitioning careers and looking for a way to organize my life and structure my learning. The concept seemed simple enough: capture everything, organize it, connect it, surface it when you need it.

I chose Notion as my platform of execution. There were already plenty of second brain templates floating around, but I chose a basic framework and figured I could grow with it.

Fast forward six weeks and my first second brain just... slipped away.

My failed system now mainly keeps track of work — but it’s far from inspiring or invigorating. I find creating systems fun, but daily upkeep tedious and tiring. The more I focus on maintaining the system, the less I want to actually use it for the things I tried designing it to do.

Fast forward to now. I use Claude Code as the base for my second brain and it just works. The system is more dynamic, adaptable, and genuinely useful than anything I’ve built before.

Here’s how to set one up.

The Stack

To get this second brain running you need:

• A computer: Linux or Mac. It may work on Windows, but I haven’t tested that.

• A markdown editor: A file editor. I use Zed, but VS Code works fine. If you’re not comfortable with git, you can use an Obsidian-based setup. Advanced users can work entirely in the terminal.

• Claude Code: Not Claude Desktop, not Claude in your browser — Claude Code specifically, because it’s agentic. It reads files, writes files, runs commands, makes decisions. As of January 2026, Claude Code is the best option for this kind of ambient, agentic work. You could try other agentic models, but if you want to see a premiere example of what’s possible, start here.

How It Actually Works

Claude manages the system, I just use it.

I don’t navigate folders. I don’t manually file things. I don’t update databases or check off todos in some interface. I just talk to Claude and things happen.

I ask Claude Code something like “what’s new?” and Claude runs the /gather command in the background and gives me a brief.

If I want to work on a specific goal, I mention it — “let’s work on the Loopcraft site” — and Claude pulls up relevant context, recent progress, and suggests next steps.

What Makes This Agentic

You’ve probably heard the term “agent” thrown around a lot lately. The definition keeps shifting a little, but here’s how I think about it: an agent is an AI that can reason and can take actions, not just generate text.

When I tell Claude Code to “process my inbox,” it doesn’t explain how to process my inbox. It actually does it — reads the files, decides where each item belongs, creates new files, moves things around, updates the log. I watch it happen. The AI has tools it can use: reading files, writing files, running commands, fetching web pages. It decides which tools to use and when.

But how does the agent know what to do? How does it know where to put files, what commands are available, how I want things formatted? That’s where markdown comes in.

Markdown as Configuration

Here’s one of the most interesting developments in this new AI paradigm – in some ways, agents are better at following human instructions than code.

You can write instructions in plain English and the agent interprets what you mean. Not what you literally typed — what you meant. “Process my inbox and route items to the right folders.” The agent figures out how to do that. You describe the behavior you want and the agent works out the implementation.

If you’re not familiar with markdown itself, it’s just a way to write formatted text in plain text files. Headers start with #, bold text uses **asterisks**, lists use dashes. It’s readable by humans and parseable by machines. Most note-taking apps support it. GitHub uses it. It’s everywhere.

At the root of my second brain project sits a file called CLAUDE.md. This is the system prompt. When Claude Code starts up, it reads this file and internalizes the instructions. I’ve written out the folder structure, the available commands, the behaviors I want — in plain English.

Don’t worry. You don’t really have to even write the markdown files. Claude does that, too.

The Loop That Ties It Together

So we have an agent that can act, and markdown files that tell it how to behave. The final piece is understanding how these work together in practice.

When I give Claude a task, it enters a loop: think, act, observe, repeat.

First, it thinks about what needs to happen. Then it takes an action — reads a file, writes something, runs a command. Then it observes the result of that action. Based on what it sees, it decides what to do next. This repeats until the task is complete. The agent acts, the markdown files guide it, and the loop keeps it moving until the job is done. That’s the whole system.

Download

For those who want to try it out, you can download the starter folders and files below, a perfect start for your very own second brain system.

GitHubLoopCraft-io

The structure of the start files are intentionally minimal — designed to be general, flexible, and scalable. You and Claude can add folders and files as you need them, customize the commands, but I’d hold off on adding too many features until you have a sense of what you actually need.

Don’t hold back on experimentation, though. That’s how you grow. You can always trash the files and start from scratch anytime

Getting Started

Once you’ve downloaded the files, you’ll need Claude Code running to bring the system to life.

Setting Up Claude Code

Claude Code is Anthropic’s agentic coding tool. It runs in your terminal and can read, write, and execute files in your project. You can install it by following the docs at claude.ai/code.

A note on pricing: Claude Code requires an Anthropic API subscription. As of January 2026, you’re looking at roughly $20/month for the Pro plan, which gives you access to Claude’s best models. There’s also a usage-based option if you prefer pay-as-you-go.

If you’re less technical and the terminal feels intimidating, there’s a newer option: Claude Code in the browser. I haven’t experimented with it yet, but it’s designed to provide the same agentic capabilities without requiring a local terminal setup. IT may be perfect for non-technical folks.

Privacy and Alternatives

I should be clear about what Claude Code is good for and what it isn’t.

This system works well for personal knowledge management, creative projects, learning, and general productivity — the kind of material you’d be comfortable sharing with a smart assistant. I use it for goal tracking, news gathering, drafting blog posts, organizing ideas. None of that is sensitive.

But if you’re working with confidential business data, medical records, financial information, or anything you’d be uncomfortable sending to Anthropic’s servers — Claude Code isn’t the right choice. Your prompts and files are processed through their API. That’s the tradeoff for using a frontier model.

Open Source Options

Dealer’s Choice

For those who need privacy or can’t justify the cost, there are other options. Open source models like Llama, Mistral, and others can run locally on your own hardware. Tools like Ollama make local model deployment accessible. Agentic frameworks like CrewAI or LangChain can orchestrate local models. You can build a similar second brain system with these tools — the markdown-as-configuration pattern works regardless of which model is doing the interpreting.

Frontier models like Claude still lead in reasoning, instruction following, and handling complex tasks. A year ago, open source models were significantly behind, but the gap is shrinking faster than the frontier is advancing. Now, for many practical tasks, they’re close enough. The trajectory matters more than the snapshot.

Pick Your Sync Strategy

You’ll want a way to keep your second brain backed up and accessible. Pick one approach:

GitHub — If you’re comfortable with git, this is the cleanest option. Your second brain becomes a repository. Every change is versioned. You can access it from any machine by cloning the repo. I use this approach — it fits naturally into a developer workflow and gives me full history of everything.

Obsidian — If you’d rather stay in a visual app, you can open this folder structure directly in Obsidian. The markdown files render nicely, you get the graph view, and Obsidian Sync can handle backup and multi-device access. Or you can use a system based around dropbox or iCloud. The tradeoff is you’re adding another layer between you and Claude — you’ll be switching between Obsidian for viewing and Claude Code for acting.

Pick one. Don’t try to do both — you’ll create conflicts and headaches keeping them in sync.

Configuring Your Sources

The one thing you should probably type yourself

One of the first things you’ll want to set up is your sources file. This lives at 05-System/sources.md and it’s how you tell Claude where to look when you run /gather.

The format is simple: just a list of URLs organized by how often you want them checked. I break mine into daily sources (news sites, AI blogs), weekly sources (podcasts, YouTube channels, newsletters), and reference sources (my own sites, key people — things Claude should know about but not actively fetch).

You can tag sources with hashtags like #ai or #design so you can gather selectively. Say “gather AI news” and Claude filters to just the sources tagged #ai. Say “gather everything” and it pulls from all of them.

The starter project comes with some example sources to show the format, but you’ll want to replace these with your own. Think about what you actually read — or want to read but never get around to. News sites, industry blogs, newsletters you subscribe to, YouTube channels you follow, podcasts you listen to. Put them all in one place and let Claude do the gathering.

First Steps

Once your sources are configured and Claude Code is running:

1. Create your first goal. Make a folder in 01-Goals/ with your goal name, add a goal.md describing what you’re trying to accomplish and why it matters.

2. Run your first gather. Say “gather news” or just “what’s new?” and watch Claude pull from your sources and compile a brief.

3. Start talking. Say “process my inbox” or “what should I work on today?” and see what happens.

The system might be rough at first. That’s fine — it grows with you. When something doesn’t work the way you want, tell Claude to update the CLAUDE.md. When you want a new command, ask Claude to make you one. The flexibility is the point.

And if you feel lost, just ask Claude to explain it. That’s part of the practice. Claude can be a powerful learning tool and teach you on your own terms.

TL;DR

• Traditional second brains fail because maintenance is tedious

• Claude Code changes the game — the AI maintains the system, you just use it

• Five commands handle 90% of workflows: /gather, /process, /summary, /goal, /run

• Markdown files configure the agent — plain English instructions, not code

• The agentic loop (think → act → observe → repeat) makes it autonomous

• Download the starter project and customize from there