In 1961, General Motors installed a 3,000-pound Unimate at its plant in Trenton, New Jersey. It was the first industrial robot arm used on an assembly line. Its job was to reach into a die-casting press and pull out hot parts, work that was dangerous and miserable for people.

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

The opportunity is not only making the AI token shinier. It is clearing the blocked path around it.

What if the most interesting AI startup is not the one with the best demo, but the one that removes the most painful bottleneck?

I spent this week learning across a strange set of sources: SpaceX AI satellites, process intelligence, AI SaaS economics, agent research, and workflow GTM.

I did not read them one by one. I ran them through a system I built for my own agents, a brain they read before they act. That detail matters, and I will come back to it.

At first, the sources looked unrelated.

Then the same pattern kept showing up.

The real opportunity was not “use AI.” It was “remove what prevents AI from becoming useful.”

I used to look at AI startups by asking what the model could do. That question made sense during the first wave. The demos were surprising. The model jumps were obvious. The app layer moved fast.

But now that intelligence is more available, the old question feels incomplete.

A better founder question is: what bottleneck does this startup remove?

As intelligence becomes more abundant, bottlenecks around intelligence become more valuable.

Those bottlenecks can be physical, like energy and cooling. They can be organizational, like memory and context. They can be operational, like workflow state and handoff. They can be social, like trust and proof.

The next great AI startup may not look like a smarter app.

It may look like a bottleneck remover.

The model is not always the constraint

The clearest version of this pattern came from SpaceX.

In a recent conversation about AI satellites, Elon Musk described the path from Earth-based compute to orbital data centers. The point was not only “put data centers in space.” The real argument was that AI scale runs into a constraint stack.

Power.

Cooling.

Chips.

Mass to orbit.

Laser links.

Manufacturing volume.

If intelligence demand keeps rising, software eventually hits the physical world. The bottleneck is no longer whether the model can generate an answer. The bottleneck is whether enough compute can be powered, cooled, connected, manufactured, and deployed.

Most startups should not copy SpaceX. That is the wrong lesson.

The useful lesson is smaller and more practical: every AI company has a constraint stack.

A video AI startup may be limited by rendering cost, not interface design.

A robotics startup may be limited by deployment conditions, not model intelligence.

An AI support startup may be limited by messy customer history, not response quality.

A vertical AI startup may be limited by integration depth, not prompt design.

The question is not “how do I build a better AI demo?”

The question is “what stops this from becoming useful at scale?”

That question points to the bottleneck.

Every AI product has a constraint stack. The stuck layer is not always the model.

Context is a bottleneck

I learned this one running my own agents. Not one agent. Three.

I use Hermes, Open Claw, and Claude Code. Different systems, different strengths. For a while, each kept its own memory. That sounds fine until you read the output side by side.

Same brand. Same project. Three different voices. One draft sounded like me. One sounded corporate. One took a stance I had already rejected weeks ago. Nothing was technically broken. But the work did not read like it came from one place. I was spending my time reconciling tone instead of shipping.

The models were not the problem. Each one was capable on its own. The problem was that they did not share a brain. Three good agents with three private memories behave like three slightly different companies.

So I gave them one shared memory to read before they act. Typed, not a pile of notes: who I am, how I write, what the project is, what was already decided. One source of truth, one voice.

Consistency turned out to be a quality problem, not a style preference. When agents disagree about the basics, you cannot trust any single output, so you become the editor who reconciles them. When they share context, the output holds together on its own.

The models never changed. The context around them did.

This is why process intelligence and company memory keep coming up in my notes. A model can answer questions. An agent needs to know the workflow it is inside.

That difference matters.

When people say AI agents are not reliable enough, part of the problem is model quality. But a large part of the problem is context. The agent often does not know the customer state, the business rules, the prior decisions, the handoff history, or what evidence matters.

It is operating without a company brain.

The value of a context layer is not only mapping a workflow. It is making the real operating system of a company legible enough for AI to act inside it.

A small sales team is a good example.

The sales agent does not fail only because the model writes weak copy. It fails because the customer history is scattered across email, CRM, calls, notes, group chats, and human memory.

Who is warm?

Who asked for pricing?

Who said “talk next month”?

Who needs proof before a decision?

Who should never receive a generic follow-up?

If that state is not captured, the agent has to guess. If the agent has to guess, the workflow becomes fragile.

The bottleneck is not text generation.

The bottleneck is company context.

Private memories create drift. Shared context turns capable agents into one operating system.

This is why I think “memory layer” is becoming one of the most important phrases in AI product design. The model is interchangeable in more places than people want to admit. The memory around the model is not.

The startup opportunity is not always to build a smarter agent.

Sometimes it is to build the context layer that lets a decent agent become useful.

A shared memory is necessary. It is not sufficient. In a real company, that memory only earns its keep when it is wired into the existing process: what the agent reads, when it runs, what it is allowed to act on. That is a harder build than a folder of notes, and it deserves its own piece.

Read more

For the last few months I have been trying to make my own AI assistant actually remember things.

Not facts in a context window. Real memory. The kind where I correct it once and it never makes that mistake again. Most days it still feels like onboarding the same new hire every morning. It forgets what I told it last week. It repeats a mistake I already flagged. It solves a problem from scratch that it already solved three days ago.

Then I watched Ayush, the founder of Answer This, explain how his team built one that does not do this.

The numbers caught me first. Answer This reached over $2M ARR with two full-time employees and a few contractors. Their internal agent handles more than 100 emails a day and has worked through more than 400 support tickets. It updates CRM records, collects feedback, and answers questions about leads and customers.

But the numbers are not the interesting part.

The interesting part is that the agent improves its own operating system. When it hits a repeated task it cannot do yet, it asks a coding sub-agent to build a tool. That tool becomes permanent. The next time the task appears, the agent already has the capability.

That is the difference between an agent I have to re-teach every morning and an agent that learns like an employee.

I used to think the main question was tool access. Give it email, Slack, CRM, Stripe, analytics, and maybe a database. Then it can do useful work.

That is only half true.

A tool-using agent can still repeat the same mistake every week. It can still answer from stale assumptions. It can still treat every repeated task as if it is the first time.

The real unit of progress is not a new workflow.

It is a new memory loop.

A useful internal agent needs three kinds of memory: factual memory, behavioral memory, and procedural memory.

There is a second idea that makes this bigger. I also watched a talk on building a self-improving company. It takes those three memories and wraps them in a loop: sensors, policies, tools, quality gates, and learning mechanisms.

That is when the agent stops being a sidekick. It becomes part of how the company improves itself.

Make the company legible first

The most important line from the self-improving company talk was simple.

If it was not recorded, it did not happen to the AI.

That sounds extreme, but I think it is right.

Most companies still run on knowledge that is invisible to software. It lives in people’s heads, Slack DMs, customer calls, founder intuition, scattered docs, support replies, meeting notes, and half-remembered conversations from events.

Humans can work this way because humans carry context around socially.

Agents cannot.

If the company wants AI to improve how work gets done, the work has to become legible first. That means recording the important inputs: emails, support tickets, user interviews, sales calls, product telemetry, code changes, churn reasons, and internal decisions.

It also means compressing those inputs into usable artifacts. You cannot dump thousands of hours of calls into a context window and expect magic. You need summaries, indexes, categories, and breadcrumbs that tell the agent where to look.

The user manual example from the talk makes this concrete. YC had thousands of hours of recorded office hours. Instead of leaving that knowledge trapped in recordings, they used it to regenerate a user manual. The result was a living artifact that could be updated as new advice appeared.

That is the company brain idea in miniature. Record reality. Compress it. Turn it into an artifact. Feed it back into the system.

This is the prerequisite for everything else. A company cannot self-improve if its own work is invisible to its intelligence layer.

Factual memory tells the agent what is true

Once the company is legible, the first memory is factual memory.

Factual memory is the agent’s access to company reality. This includes the codebase, database, docs, pricing rules, subscription logic, customer records, support history, product behavior, and analytics.

Read more

Subscribe now

Every Monday, I open my AI agent and the first thing I do is re-explain who I am, who the customer is, and what got decided last week. The agent is fast. The output is good. But I am the one carrying context across, every single time.

Then on May 22, Shann Holmberg posted something that made me sit up. He sketched an architecture diagram for a “company of agents” and named the missing piece: “don’t think about gBrain as an agent, it’s the shared memory layer that lets a company of agents act like a team.”

That framing landed. I had been hand-building the same shape for months without naming it. And once I had the name, the question got sharp.

What if the problem with your AI agent isn’t your model, your prompts, or your tools? What if your agent just doesn’t have a brain to read before it does anything?

I tried the memory products. None of them fit.

I kept building “smarter” agents and kept ending up as the connective tissue. Re-explaining context. Copy-pasting last week’s notes. Repeating the same intro every Monday. The agent was getting faster, and I was getting more tired.

So I tried the memory products people name when this comes up.

mem0 auto-extracts facts from your conversations into a vector database. The system listens, decides what’s important, and stores it for retrieval. Good fit for chat personalisation. Wrong fit for what I needed, which was a hand-curated set of facts I could review and edit.

Letta (formerly MemGPT) wants your agent to run inside their runtime. Three memory tiers, core, recall, archival, all addressable through their API. Elegant design. But I was buying a framework, not a folder. The lock-in cost was real.

Cline’s memory bank was the closest in form. Markdown files in a folder called memory-bank/, read at the start of every session. But the folder is partitioned by document type: projectbrief.md, activeContext.md, systemPatterns.md, progress.md. Right shape. Wrong axis. Also scoped to a single coding project.

What I actually needed was different. A clean, curated set of files about the people, companies, and concepts I work with. Readable by any of my agents. Editable by me. Persistent across projects, not tied to one repo or one runtime.

What I’ve actually been doing

For the last two years, I’ve been building agent infrastructure for my own startup. Most of that time was spent learning that the bottleneck isn’t the model. It isn’t even the prompt. It’s what sits underneath the model when the agent wakes up. Models have been good enough for the last twelve months. The thing that decides whether my agents are useful or annoying is what they read before they do anything. That is the layer worth getting right.

The non-obvious part: axis matters more than format

Here’s what I learned the hard way.

Agents don’t forget because models are weak. They forget because most setups run them as standalone runtimes with no shared memory layer underneath. The fix isn’t a bigger context window or a smarter prompt. It is a typed, persistent brain that every agent reads before doing anything, and that the orchestrator writes durable decisions back to.

But everyone building agents already half-knows that. The thing nobody talks about is the actual design decision: what do you type the folders by?

Pick the wrong axis (document type, time slice, conversation thread) and you get a brain your agents can’t really use. Pick the right axis, which I think is entities, and your agents start behaving like a team.

Here is what that looks like in practice.

The four folders carrying my agents

I run a folder called gbrain-data/ underneath my own agent setup. Inside it, four folders are doing the heaviest lifting right now.

people/: every prospect is a folder, not a prompt

Every person I plan to reach out to gets a folder. The agent scrapes their LinkedIn, Twitter, personal site, and GitHub once. It consolidates the signal into one profile, with source links kept inline so I can audit later.

The next time I touch outreach, the agent doesn’t re-research from zero. It reads the existing profile and appends what’s new. Tokens go to writing the message, not to discovering the person for the fourth time.

The downstream effect is the part I didn’t expect. Outreach drafts now reference what someone actually shipped last quarter, in their own vocabulary, on the third reply not the seventh. The agent isn’t smarter. It just isn’t starting cold every time.

concepts/: explain it once, never again

Company philosophy, product theses, planned initiatives. All of it lives here.

The cost of explaining “what am I trying to build” dropped to zero after the third time I wrote it down. More importantly, the cross-agent payoff started showing up. The newsletter agent and the outbound agent now share the same answer to “what’s the positioning?”, because they read the same file.

When the positioning shifts, I update one place. Every agent picks it up on its next read.

Read more

Subscribe now

In 1480, a hand-copied Bible took a year and cost the price of a house. By 1500, you could buy one for the price of a wheel of cheese.

The scribes didn’t all become beggars. But the ones who survived weren’t copying anymore.

I keep coming back to this because the same shape is playing out right now. Last month I shipped a feature in an afternoon that, two years ago, would have crossed four roles and three weeks. PM spec, design review, engineering sprint, QA pass, marketing push. Now it’s me, an agent, and a Stripe link.

So who got specialized out of a job? And what’s left worth specializing in?

Short answer: nobody got specialized out. Specialization itself got split in two. The surface (frameworks, syntax, templates) went free, the foundations (first principles, judgment, taste) got scarcer and more valuable. On top of those foundations, a new skill tree replaces the old one: three new relationships with the customer, the agent, and language itself. That’s the whole article.

The gap I watched widen

I used to think AI would make everyone a generalist. I was wrong.

I watched two patterns happen at once. Junior people got faster. And shipped more wrong things. The senior people I respect didn’t get displaced. They got louder. Their judgment compounded against AI speed.

The gap widened. Nobody got specialized out. Specialization itself got split in half.

The surface (frameworks, templates, syntax, the things bootcamps teach) became free. Any agent produces it.

The foundations (first principles, the basic science of your craft, judgment of what’s right) became the only thing left that separates senior from junior.

On top of those foundations, a new skill tree replaces the old one. It isn’t another craft. It’s three relationships: with the customer, with the agent, and with language itself.

Two illustrative archetypes on the five axes I think matter now. The Pre-AI Specialist (blue) won by going deep on one craft and shipping into a relay race; the Post-AI Producer (orange) wins by being balanced across all five and owning the chain end-to-end. The shapes are the argument. The specific values are picked to make the contrast legible, not measured from anyone.

This isn’t a job title. It’s a loadout. And the rest of this piece is how to grow each axis.

This isn’t new. It’s just fast.

Before I get to the how-to, the part that grounds it for me.

The printing press took roughly fifty years to do what AI is doing in five. The structural shape was the same. A surface specialty (copying text) collapsed in cost. By something like 99% in less than two generations. Hand-copied books gave way to print runs. Scribes, who’d been a respected guild for a thousand years, mostly disappeared from that role.

But the foundations didn’t disappear. Literacy, scholarship, editorial judgment, knowing what was worth printing. These got more valuable, not less, because the volume of text exploded and somebody had to curate it. The scribes who survived became editors, type designers, proofreaders. They moved from execution to judgment. Reviewer, not producer.

And three new relationships appeared. With the customer: the bookseller networks, with the Frankfurt Book Fair starting in 1454 as the original distribution moat. With the machine: typesetters and pressmen. The first generation of harness-fluent operators. With language: print forced the standardization of orthography, page numbers, indices, controlled vocabulary. The first shared language with the machine.

Compensation followed output, not seat. Scribes got paid per page. Publishers earned royalties on print runs they bet on. Booksellers earned the spread. The economics inverted from “paid for the work you did” to “paid for the work that sold.”

You can see the same shape in photography against painting after 1839. Cameras made literal accuracy free. Portrait painters who’d specialized in realism lost the market. The painters who survived (first the Impressionists, then everyone after) went where cameras couldn’t follow. They didn’t fight realism. They moved up the stack to what was irreducibly human: light, mood, abstraction, concept.

I’m not saying AI is the printing press, or that this time will be exactly like 1500. I’m saying the shape of the shift (surface goes free, foundations get more valuable, new relationships emerge, comp inverts) has happened before, and the people who recognized it early got rich and famous.

The ones who didn’t became Luddites.

Step 1: Sharpen the fundamentals

This is the part of specialization the printing press didn’t kill. Don’t kill it now either.

What it is. First principles plus the basic science of your craft. The thing that lets a senior engineer debug a system they’ve never seen before. The thing that lets a senior PM smell a fake demand signal across the table. The thing that lets a senior marketer rewrite a headline and have it convert three times.

Why it matters now, more than before. When execution is free, the only remaining variable is “is this the right thing to execute?” That question gets answered by fundamentals, not by frameworks. AI will write your React component. It will not tell you that you shouldn’t have built that feature.

There’s a study that captures this directly. METR ran a randomized trial in 2025 with sixteen experienced open-source developers, on real tasks in mature repositories they’d worked in for an average of five years. The developers predicted AI would make them 24% faster. After the experiment, they felt 20% faster. The actual measurement: they were 19% slower(paper).

Read that again. The most expensive people in software, using the best AI of the moment, on a task they knew cold. Slower. Because the harness around the model was shallow and their judgment had to do all the work.

The lesson isn’t “AI is bad.” It’s: without fundamentals, you can’t tell if AI is wrong. Without harness fluency, telling it is wrong costs more than doing it yourself. Fundamentals and harness fluency are the two axes that turn raw AI capability into output.

Concrete moves:

1. Audit the last ten outputs an AI generated for you. For each, write one sentence explaining why it’s correct from first principles. If you can’t write the sentence, that’s your study list.

2. Replace “how would you build this?” with “why does this work?”When pairing with juniors. AI answers the first question for everyone. The second is the one it doesn’t.

3. Read the boring primary sources. Original RFCs. Original textbooks. The papers that things are named after. AI summaries skip the load-bearing nuance. And the load-bearing nuance is exactly the difference between senior and junior judgment.

I had a moment last month where a junior on a project I was advising generated two hundred lines of correct code to solve a problem first principles would have killed in one sentence: this state shouldn’t live on the client at all. The output was right. The decision was wrong. AI flattens the gap on the first. It widens the gap on the second.

Step 2: Grow the distribution skill tree

The scribes who survived didn’t just know how to spell. They knew which booksellers to stand next to. Same now. Sharp fundamentals tell you what’s right; they don’t tell anyone you built it. The next three layers all push outward into the relationships that turn output into impact, and distribution is where I’d start, because that’s where most builders today are weakest.

The new moat. Boring. Necessary. The reason most of the talented engineers I know aren’t paying their rent from what they build.

What it is. Networking, sales, customer development, partnerships, community, public writing. The work that used to belong to a sales function. Now it belongs to every producer.

Why it matters. Building is cheap. That’s the whole previous essay. The bottleneck moved.

Look at the numbers. The median SaaS company in 2024 spent $2.00 on sales and marketing to acquire $1.00 of new ARR. Up 14% in a single year. The average B2B SaaS now spends roughly $1,200 to acquire a single customer. Payback periods stretched to 23 months. Meanwhile, the cost of building a comparable product dropped by an order of magnitude: an MVP that ran $140K in 2022 can run $14K now, sometimes less.

Build cost down 90%. Acquire cost up 14% in one year, and still rising. The crossover point passed a while ago. Distribution is now more expensive than the thing being distributed.

What that looks like at the employee level: the engineers I know who can ship a SaaS in a weekend and can’t get to ten paying users in three months. The product was never the problem. The skill they don’t have is talk to thirty strangers a week and not flinch. Cold outbound. Public writing. Community presence. The boring reps.

Concrete moves:

1. Pick one distribution sub-skill. Cold outbound. Community presence. Partnerships. Public writing. Customer interviews. One, not all. Treat it like a real skill, not a side activity.

2. Run weekly reps. Thirty customer conversations a week is the new LeetCode. Track them in a spreadsheet. The compounding takes six months. The first month feels useless. Do it anyway.

3. Negotiate compensation that follows output. If you produce end-to-end and ship sales, share in the sales. Per-producer bonus, not per-role salary. The companies that resist this will lose their producers to the ones that don’t. (More on this below.)

If you’re reading this and recoiling (I’m an engineer, I don’t want to sell), keep reading. There’s a path for you too. But you should know that you’re picking it on purpose, not by default.

Step 3: Master the agent workspace

This is the longest section. It’s also where I think the biggest 10× lives.

What it is. Knowing the runtime. Not “I use Claude.” Knowing how Memory, Skills, Plugins, Hooks, Sub-agents, and the scheduler compose into something that does work while you sleep.

Why it matters. Two people use the same model. One gets 1× output. The other gets 10×. The model is identical. The harness fluency is not. This is the new keyboard-shortcut mastery. Except the leverage is two orders of magnitude higher.

There’s a survey number that captures the gap. Stack Overflow’s 2025 developer survey: 84% of professional developers use AI tools. Only 29% trust them. Down from 40% in 2024. The biggest single frustration, named by 66% of developers, is dealing with “AI solutions that are almost right, but not quite.” The second-biggest is debugging AI-generated code taking longer than writing it from scratch.

That gap between using AI and trusting it is the gap that harness fluency closes. The people who trust AI output aren’t smarter. They’ve built a workspace where AI output can be trusted by construction: scoped to one job, gated by hooks, reviewed against shared memory, executed by a sub-agent with clean context. The harness does the work that trust would otherwise have to do.

The agent workspace. One diagram

Six surfaces. Six things to learn. Most people only know one or two.

The difference between 1× and 10×

Most people prompt like this:

Can you help me write a competitor analysis? My company is [explains for
200 words]. The competitors are [pastes 5 URLs]. Please summarize their
positioning, pricing, and recent launches in a table.

The agent does the job. You do it again next week. And the week after. Same context, same setup cost.

Here’s the same task, leveraging the workspace.

CLAUDE.md. Memory, written once:

## Company

Curiosity Insights. Practitioner newsletter on AI agents,
single author, voice: direct/curious/practitioner,
audience: Gary Tan-style builders.

## Competitors-to-watch (auto-updated)

- substack.com/@latentSpace
- techcrunch.com/category/ai
- ...

skills/competitor-watch/SKILL.md. Job description, written once:

---
name: competitor-watch
description: Use when the user wants a weekly competitor brief.
---

# Competitor Watch

## Inputs

- Read CLAUDE.md → Competitors-to-watch list.

## Output (always this exact shape)

| Competitor | What changed | Why it matters | Suggested move | Source |

## Schedule

Run every Monday 09:00 (scheduler).

## Handoff

Append to briefs/<YYYY-WW>.md. Notify via desktop hook.

Then, every Monday, without me touching it, the runtime fires:

/competitor-watch

Two words. The agent reads memory, the skill knows the format, the plugin fetches the URLs, the hook drops the file in the right place, the scheduler runs it again next Monday. Same model. Different harness fluency. Roughly 10× the leverage over the lifetime of the workflow.

Three patterns worth learning first

If you’re starting from zero, this is the order I’d grow harness fluency:

1. Memory before re-pasting context. Any time you catch yourself re-typing the same paragraph of company / project context, stop. Put it in CLAUDE.md. The agent reads it for free on every session.

2. Skills before re-prompting. Any time you re-type the same multi-paragraph prompt for a recurring task, turn it into a SKILL.md. Reusable behaviour, no re-prompting.

3. Sub-agents before mega-prompts. Long, branching tasks belong as a chain of Explore → Plan → Task sub-agents with clean context boundaries. Not one mega-prompt that loses track halfway through.

This isn’t an exhaustive list. It’s the cheapest 80% of the leverage.

Step 4: Build the shared language

The discipline that makes everything above work.

Read more

Subscribe now

Most weeks now I run three AI agents in parallel — two on a VPS, one on my laptop. Last week alone they worked through fundraising strategy, a stack of GitHub repos and emerging tech trends, meeting notes, and code. Same class of model in all three windows. I was the conductor, not the typist. A year ago I couldn’t have done this — not because the models were worse, but because I hadn’t yet assembled the thing that made it possible.

The same week, two signals from the wider ecosystem. Stripe gave AI agents wallets — an agent can now buy a $35 vitamin C serum on your behalf without ever touching your real credentials. A developer named mvanhorn shipped cli-printing-press, a tool that rewrites third-party APIs into agent-native binaries: typed exit codes, 60-80% fewer tokens than the MCP equivalent. “Exit code 0 = done.” Agents are about to act in the real world. The substrate is being rebuilt to let them. Most people’s local setup hasn’t caught up.

There’s an old Chinese saying from the Analects: 工欲善其事，必先利其器 — “A craftsman who wants to do good work must first sharpen his tools.” The word for tool is 器. And in 2026, the 器 isn’t the model. It isn’t even the agent CLI. It’s the agent workspace you assemble around them. Almost nobody is assembling one.

Tools come and go. Your workspace is yours.

Most “AI tooling” content fights over the wrong layer. Which model. Which IDE. Which subscription. Which $200/month plan.

It’s the wrong question. Models are commodity already. Agent CLIs are converging fast — Hermes, Claude Code, OpenClaw, Codex, Cursor all read markdown config files, all support MCP, all get easier to migrate between every quarter. None of these are your moat.

The only thing that doesn’t get replaced when you switch tools is the workspace you assembled around them.

I’ve spent the last 2-3 years on one hypothesis: human instructions to machines should compound, not dissipate. Every time you re-explain context, you’re paying interest on a debt that should have been an asset. This article is about what you can do today, by hand.

The three layers of an agent workspace

An agent workspace has three layers. Each one is invisible to anyone else. Each one compounds with the next.

Layer 1 — Project context. “Who you are. What we’re doing.”This is the file your agent reads on entry. CLAUDE.md, AGENTS.md, whatever the agent calls it. It tells the agent: my project, my role, what good output looks like, what to avoid. Static. Without it, every session starts from zero.

A practical example: this Substack repo has a CLAUDE.md that turns a generic Claude Code into a Curiosity Insights writing assistant. Brand voice rules. SOP checklist. Per-stage workflow. Same model, different identity, in one file.

Layer 2 — Behavioral rules. “How you work.” Hooks. Permissions. Settings. The rules that run every session, every tool call. Without this, you keep correcting the same mistakes — please don’t push without my approval, please format the file, please don’t rm -rf the docs folder.

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

2025 marked a historic turning point for AI investing. More than $192 billion—53% of all global venture funding—flowed into AI, the first time in history AI surpassed every…

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

Read more

Subscribe now

The Problem: Why AI Products Plateau

Most AI-driven products today are trapped in a paradox of early excitement and fast decay. Teams add GPT-powered assistants, smart summa…

Read more