A few months ago, a CEO at a VC firm asked me to describe my skillset.

I took a breath and did my best. Marketing, I said. Brand positioning. Design taste — the kind where you can look at a layout and know immediately what’s wrong without needing a rubric. AI systems: I build and operate agent infrastructure for research, editorial, quality review, and publishing. Content engineering. PMM. I’ve worked on product direction, helped take a company to acquisition, shipped consumer apps, and I write a newsletter about all of it.

She nodded slowly. Processing it.

Then… “So what’s the job title for that?”

I didn’t have one.

I still don’t have a perfectly crisp one. But I’ve been thinking about it a lot, and I think the job I’m doing (the one I want to get increasingly good at) is best described as *marketing engineer.*

I’ve been intentionally avoiding the term ‘Engineer’ like the plague for fear that my far more technically gifted, far earlier in life friends might roll their eyes at me in disgust. But I think the job has been, inevitably, emerging for a while. It doesn’t necessarily have a lane yet, doesn’t have a canonical job description, doesn’t have an industry body lobbying for it. It’s a thing that, increasingly, people like me are falling into rather than planning for.

Which is how I got here.

What a marketing engineer actually is

A “technical marketer” usually means someone who can read a dashboard, set up UTM parameters, and speak coherently with an engineer. Useful. Not the same thing. A “growth hacker” is mostly dead framing, and what it described was usually performance marketing and light product intuition stapled together with the promise of hockey sticks. Marketing ops and rev ops are different jobs. And a product marketer who learned Python is still a product marketer who learned Python… and someone who nobody wants to hang out with at the company retreats.

A marketing engineer is someone who builds governed systems that turn market evidence into measurable marketing action.

The emphasis is on *systems* and *governed.* The engineering is not about code specifically. It’s about the design of something reliable, maintainable, and honest about what it can and can’t do. It’s about thinking clearly enough about a problem that you can specify it precisely. And it’s about being willing to be accountable to what the system actually produces, not just what you intended it to produce.

That last part is the crucial element.

The best budding marketing engineers I can think of tend to share a specific combination of capabilities… they understand how buyers actually think, they can encode that understanding into repeatable processes and tools, they can work at the intersection of strategy and implementation without losing either one, and they are weirdly comfortable sitting at the junction of craft, judgment, and technical systems.

It’s also a job where taste matters in a way that’s hard to explain to a CFO. Not aesthetic taste for its own sake. Taste as a quality signal. The ability to know when a system is producing something good versus something technically correct but wrong, and to course-correct without burning the whole thing down.

This is different from “I have opinions about fonts.” It’s more like… when you run thirty AI-assisted content variants and twenty-seven of them have the structure right but are somehow missing the thing that makes a real person stop scrolling, you can tell immediately and you can say precisely why.

That’s a trained sense, and it atrophies if you stop using it.

Most marketing structures don’t build this sense. They reward throughput.

The long way here

I was a filmmaker first.

Not in a “I made some YouTube videos in college” way. In a “I spent years editing countless hours of footage in a bedroom trying to figure out what made a sequence of clips feel like something instead of just a bunch of clips” way. I wanted to be a filmmaker. That was my “plan”.

This is important context because what filmmaking taught me was not creative expression or artistic vision or any of the words people put on filmmaker bios. What it taught me was this… the decisions that determine whether something is good are invisible to the audience. The edit, the pacing, the order, the specific moment a cut happens. The thing that makes a motorcycle doc legendary instead of just footage of piping and flybys is a hundred undetectable decisions made at 3am by someone who cares more than the situation requires.

That’s the skill. And I had no idea at the time that it would transfer to, quite literally, everything else.

I ended up in content marketing at a startup almost by accident. I was doing strategic direction work for large enterprise brands at an agency and someone needed help with content and I needed money and that was the whole strategic plan. But within a few months, I noticed something… most of what passes for “marketing strategy” at early-stage startups is actually a list of activities with no underlying model. We post because we should post. We write a blog because SEO is good. We send a newsletter because people recommended it. There’s no governing logic. No way to know if it’s working. No mechanism for learning.

This bothered me the same way bad editing bothered me. Not aesthetically. Functionally. A system without a feedback loop isn’t a system. It’s a to-do list.

So I started building one.

A real content system: with intake, voice standards, source banks, quality gates, repurposing logic, and measurement that connected content to real buyer behavior. Not a content calendar. A system that could learn.

By the time I was done, other people at the company wanted to know how we built it. Then people at other companies started asking. And that is how, eight months after I joined Averi, the company decided to pivot around the content operating system I had built and turn it into the product.

The moment the system became a product

I want to tell this story accurately because I’ve seen it get compressed in ways that lose the part that actually matters.

I didn’t walk into Averi with a product vision. I walked in with a marketing problem and an emerging, though unfulfilled, systems instinct. The product vision came from watching the system work and realizing that the hard part, the part no one had turned into software yet, was all the stuff that happened *before* the draft.

Most AI content tools start at the draft. That was already too late.

The real work was what is the company trying to be known for, what does the buyer actually believe before they encounter you, what evidence do you have that your claims are true, how do you translate that into a durable content strategy that doesn’t turn into random production.

That’s a system. And systems can be encoded.

After the pivot, I worked directly with the CTO to guide product direction and propose features. This is not how I thought my marketing career would go. I was a filmmaker who fell into agencies, then fell into SaaS content marketing. And now I was sitting in product conversations trying to articulate why “the AI should produce the brief before the draft” and “the content system needs a memory layer, not just a history tab” and “quality is not a vibe check at the end, it’s a constraint you build in at the beginning.”

What I was doing, and I didn’t have a name for it at the time, was effectively marketing engineering. Encoding judgment into a system. Making the implicit explicit. Building something that could operate at scale without losing the things that made it good.

By the time Averi reached acquisition, the content and growth system had helped scale the company to more than 3 million monthly Google impressions, more than 100,000 AI citations, and more than 35,000 monthly organic site visits. But the more durable thing the experience produced was a way of thinking. A set of design principles for how marketing systems should work.

That’s the thing I carried out.

The professional uncanny valley

Here is the weird part about living at this intersection… no one knows what to do with you at first.

Traditional marketing people think you’re too technical. Engineers think you’re too soft. Product people think you’re too opinionated about things that aren’t in the roadmap. And every time you try to explain what you actually do, you end up making it sound like either “I’m just a really thorough marketer” or “I’m a frustrated engineer who couldn’t code” when it’s neither.

There’s a specific version of this that happens in job interviews.

You’re applying for a PMM role and the hiring manager is looking for someone to own messaging and run launch campaigns. You start talking about systems architecture and feedback loops and they smile politely. Or you’re in a conversation about a more technical role and you mention “marketing” and the energy shifts slightly because now they’re not sure what you are.

It’s a professional uncanny valley. Close enough to recognizable roles to confuse people, far enough from any single category that you don’t fully fit.

I’ve learned to stop apologizing for this. The roles that compound the most are usually the ones that don’t fit neatly.

But there’s a real cost to operating without a category… you don’t get the community, you don’t get the canonical career path, you have to define the standard yourself. And when you’re doing work that’s genuinely at the frontier of what a marketing person does, there’s no external signal that tells you you’re doing it right.

You have to develop your own.

It’s essentially perfect for me.

Of course I ended up here

Most of my career has been a refusal, conscious or otherwise, to stay inside the job I was hired to do.

I entered through video and started asking brand questions. I entered marketing and started building systems. I built the system and started asking product questions. I moved deeper into SaaS and started wiring together agents, verification gates, design specifications, and operating loops.

On a résumé, that can look restless. Maybe even unfocused. I have never been especially good at following the path that already exists or staying inside the box that makes a role easy to explain. Every time I got competent at one discipline, I became interested in the machinery underneath it and wandered into the next room.

For most of my career, that made me harder to categorize. Now the technology is catching up to the way I already work.

The old boundaries made more sense when each craft required a separate set of tools and a separate specialist to operate them. AI is collapsing the distance between an idea and a working artifact. A person with taste, market judgment, and enough systems fluency can now move from research to positioning to interface to prototype without handing the work through five disconnected teams.

That does not mean one person should become a mediocre version of five specialists. I have no interest in cosplaying as an engineer because an agent helped me ship an app. The opportunity is to become unusually good at connecting the disciplines: to know enough about each one to define the problem, direct the work, recognize when the result is wrong, and pull the pieces into one coherent system.

Seen that way, marketing engineering does not feel like a random title I found. It feels like the first role shaped like the way I have always worked.

The emerging technology did not suddenly make me different. It made the collection of things I was already obsessed with more useful together.

Why this particular combination matters more now

AI didn’t create this job. But it made it legible, and it raised the stakes considerably.

When AI tools became good, the execution layer got cheap. You can now produce ten times as much content, ten times as many variants, ten times as many audience-segment messages without proportionally more human effort. That’s real. Every marketer who hasn’t noticed this is about to have a bad year.

But the demos always skip this part: volume without judgment produces noise with better grammar.

I’ve watched this play out in real time.

A content team adopts AI tools and goes from producing 10 pieces a month to 80 pieces a month. Open rates drop. Engagement drops. The content *sounds* fine. It hits all the structural markers. But it doesn’t have the specific thing that made their original 10 pieces worth reading… a point of view rooted in something true about the buyer, written with enough specificity that it couldn’t have been written about any other company.

AI can produce the structure. It can’t produce the evidence.

It can’t tell you which of the thirty frames you could use actually aligns with what your best customers say when they explain why they chose you.

It can’t decide that the blog post about your feature is actually hiding the more important story about the problem the feature solves.

It can’t feel the difference between a headline that will stop a real person and a headline that a language model thought was the right shape of a headline.

Those are judgment calls. And judgment, unlike execution, doesn’t get cheaper when you add compute.

There’s a cleaner way to describe the role shift this forces.

The most capable AI systems right now are most useful when they’re running the system, not doing the task. Anthropic’s latest models are designed to plan, delegate, verify, and keep a set of workers pointed at one finish line — not to be the person typing every keyboard command. The person who designed that system still has to exist. Someone has to define the destination, set the constraints, own the quality gates, and decide what counts as finished. That work cannot be automated away. Someone has to do it.

The people who will get squeezed over the next decade are the ones who operated primarily in the execution layer: who produced content, ran the playbook, managed the calendar, and called it marketing.

Those who will compound are the ones who moved into the orchestration layer — who can encode the judgment, design the system, delegate the labor to cheaper agents, and inspect what comes back. Not just prompts. Governed systems with real inputs, real quality gates, and a definition of done that can’t be satisfied with a confident paragraph.

The technical part isn’t “knowing how to code.” It’s being able to think clearly enough about a problem that you can specify it precisely. Which, ironically, turns out to be the same skill that makes code work, and the same skill that makes marketing work, and the same skill that makes any tool do something useful rather than something expensive.

What I’m building right now

I said earlier that the lasting thing I took from Averi was a way of thinking. Let me make that concrete.

Right now, I coordinate an AI agent infrastructure that handles research, editorial planning, content drafting, quality review, and distribution across this newsletter and my LinkedIn presence. It runs on a set of voice standards, taste libraries, anti-slop review scripts, source banks, and quality gates that I built and maintain. The system doesn’t write for me. It operates from the judgment I’ve encoded into it, and I review every output before it goes anywhere.

At Cohley, I’m building PMM workflows that treat AI as a governed collaborator: with explicit constraints, documented decisions, and accountability to real measurement rather than activity metrics. The goal is not “we use AI in marketing now.” The goal is a specific system I can instrument, run a controlled intervention through, measure, and document as a case study.

Alongside that, I’m building something exciting, a product for the agentic web, where I’ve been running a design-authority-first workflow… write the full product specification before a single screen gets built, use that spec as the governing document for every AI-assisted design and code output, and treat every deviation from the spec as a signal about whether the spec or the output is wrong.

This is marketing engineering applied to product: encode the judgment before you start producing.

And I’m writing here, obnoxiously often in this newsletter, about all of it.

Not because I have a completed arc to share. Because naming and defining a field is part of creating it, and someone has to do it in public while it’s still being figured out.

I volunteer as tribute.

The honest gap

The cleaner version of this essay would tell a story of a completed arc: built the system, measured it, packaged it, sold it to fifty CMOs at a conference, now accepting consulting inquiries.

The actual state is more provisional than that.

I have a lot of architecture.

I have real proof of work: the Averi content system, the acquisition outcome, the personal publishing infrastructure, the current AI agent setup, the startup design-authority workflow. But the gap I keep bumping into is the distance between designed and built and exercised, repeated, measured, and packaged into something another person could use.

I’ve built content systems that worked inside specific contexts. I haven’t yet taken one fully through the complete loop to my satisfaction… first deployment to measurable business outcome to public case study to replicable process that someone else can pick up and run.

That’s the next phase. Not more system design. More disciplined operating proof.

Part of why this is slower than I’d like: companies don’t always have clean data. Stakeholders don’t always align on the metric. “Marketing engineer” is a hard sell when the dominant mental model of what a PMM does involves a lot of slides and a lot of meetings and a quarterly review where you show how many pieces of content the team produced. And the feedback loop between “built a better system” and “here is measurable evidence that the system produced better outcomes” is long.

Six months at minimum. Sometimes a year.

I’m learning to be okay with that timeline without using it as cover for not doing the work.

There’s also a version of this I’m less comfortable admitting: I’m more comfortable designing systems than I am sitting in the uncomfortable middle of operating them.

The design phase is satisfying.

The operating phase is where you find out all the ways the design was wrong.

I’m working on developing the same appetite for the operating feedback as I have for the initial architecture. That’s the actual growth edge, not learning another tool.

Why I want to be one of the best

Not “the best.” That framing is mostly for LinkedIn headlines. But one of the best. A person who, when someone else trying to figure this out goes looking for examples of what marketing engineering actually looks like in practice, finds my work and finds it worth learning from.

I want this for a few reasons, and I’m going to be honest about which reasons are respectable and which ones are just about ego and blind f*cking ambition.

The respectable reason: this field is going to matter enormously over the next decade, and it doesn’t have enough good practitioners yet. Someone who does it at a high level and documents it publicly is creating reference material that didn’t exist before.

That’s genuinely useful.

Not in a noble-calling way, but in a “the world will actually work better if more marketers know how to think about systems and proof and accountability” way.

The less respectable reason: I want to be known for something that’s true about me. Not “he was a good marketer at a few companies.” Something with more precision than that. The specific thing I can do, at the specific intersection I’ve spent ten years finding, turned into a body of work that’s unmistakably mine.

I had aspirations of reaching that level in hockey. I had a version of this in filmmaking. I had opinions about editing that I would have defended to anyone. I had a taste that was identifiable. I lost some of that legibility in the transitions between roles, and I want it back in the field where I’ve ended up.

What it actually takes

I’ve been thinking about this in terms of what makes a marketing engineer someone clients, employers, or readers would actually trust to build something consequential.

The proof has to be real and public.

Not “I worked at a company where something good happened” but “here is a specific system I designed, here is what it produced, here is what it cost, here is what I’d do differently.”

The acquisition outcome at Averi certainly helps. The metrics help. But they’re not enough by themselves, because an outcome you contributed to is not the same as a system you can reproduce.

The technical independence has to be at the right layer.

Not “I can write Python” but “I can specify a problem precisely enough that a code agent can implement it, and I can verify the result without taking the agent’s word for it.” That’s a meaningful line to cross, and most marketers haven’t crossed it.

It’s also different from being an engineer… I’m not writing production code. I’m being precise enough about what the code needs to do that good code becomes possible.

The judgment has to be visible and documented.

Not inside a strategy deck that lives on a private drive but in the work itself: in DESIGN.md files, in CLAUDE.md files, in structured handoffs, in documented decisions with reasons and outcomes attached.

The standard I use for this: could a capable person read the documentation I’ve left and understand what the system does and why it was designed this way? If not, the judgment isn’t actually encoded. It’s still in my head, which means it leaves when I do.

And the field has to be defined.

Not by waiting for a job board to create the category but by writing about it, building it publicly, showing the work in real time. That’s what this newsletter is for. That’s what the design-authority for my upcoming company’s workflow is for. That’s what the proof bank I maintain is for. Define it by doing it well enough that other people can see what it looks like when it’s working.

Five questions that will tell you if you’re already one

1. When you inherit a marketing system from someone else, do you immediately want to understand the underlying model, or do you just learn where the buttons are?

2. Can you write a real specification for a marketing asset (a contract with inputs, constraints, quality tests, and a definition of done) and hand it to an agent or contractor and get something useful back?

3. Do you have documented opinions about *why* something worked, or just the results?

4. When AI produces something technically correct but wrong, can you name precisely what makes it wrong? Not “it doesn’t feel right.” The actual thing.

5. When a system you built stops working, is your first instinct to look at the design, or to blame the tool?

If most of those are yes, you’re probably already doing this job. You just might not have a name for it yet.

That seems to be where we are as a field. A job that exists but doesn’t have a title. Work that matters but doesn’t have a canonical career path. A set of skills that compound but don’t show up legibly on a résumé designed for a different era.

I started as a kid editing skate footage until it felt like something. The edit no one sees is the thing that makes the thing worth watching.

I’m still doing that, just in a different medium.

Being early to a category is usually better than arriving late to a crowded one.

The work is to build the proof. Not the theory. The proof.

I’m working on it.

-zc

P.S. If you’re not subscribed to Don’t Feed The Algorithm, you’re getting this from someone who thought it was worth sharing.

I write about AI, marketing systems, and staying human while building things that matter. It’s a good newsletter, I’m told by my mom and a few thousand strangers.

Subscribe now

Rabbit hole for the overcaffeinated:

- Pure UI — Guillermo Rauch’s 2015 essay on declarative UI. The short version: if you can encode state precisely enough, the rendering becomes almost automatic. This is where the `DESIGN.md → agent → rendered interface` workflow comes from, but the original insight is broader and applies to any system where specification quality determines output quality. Which is what marketing engineering actually is.

- Marketing Technology Landscape Supergraphic — Scott Brinker at chiefmartec.com has been mapping the MarTech stack for 15 years. The point is not the number (8,000+ tools). The point is that this complexity requires someone who can make sense of it at a system level, not just operate individual platforms. That person needs a name.

- What distinguishes the best growth thinkers — Lenny Rachitsky on mental models over tactics. Same underlying premise: depth in one area, judgment across the whole.

- The Next AI Skill Isn’t Prompt Engineering. It’s Graph Engineering. is a related argument about how AI changes the skill premium in knowledge work.

Before I wrote this article, my AI system checked the live archive of this newsletter, inspected the current draft queue, compared the recent topics, and recommended a few directions that would not sound like I had discovered the same idea for the fourth time this month.

I picked one. It found research. I started writing.

This is a stupid amount of capability.

I have AI agents that can research companies, inspect products, turn meetings into decisions, pressure-test positioning, help build software, keep track of my writing, and tell me when a draft is beginning to sound like a man trapped inside a LinkedIn carousel.

Work that once required a free afternoon can happen during a coffee. Work that once required another specialist can at least reach the point where I know whether the idea deserves one. A vague thought can become a brief, a prototype, a research packet, or a nearly finished essay before I have fully decided what to do with it.

So why do I still feel perpetually out of time?

I think I finally understand the answer.

AI has made action cheaper. It has not made attention infinite. The distance between idea and artifact keeps shrinking, which means more ideas survive long enough to ask something from me.

The old constraint was getting started.

The new constraint is living with everything I can now start.

The time savings do not stay saved

When a task that took four hours suddenly takes forty minutes, I do not gently place the remaining three hours and twenty minutes into a tasteful little savings account.

I f*cking spend it.

I investigate another idea. I open another project. I ask an agent to research the thing I was curious about during the first thing. The result appears while I am in a meeting, so I skim it, make two comments, and create a new branch of work that now has enough shape to feel irresponsible to abandon.

AI does not only help me finish work. It makes more work feel possible.

That distinction showed up in an eight-month ethnographic study at a 200-person technology company. UC Berkeley Haas researchers observed employees and conducted more than 40 interviews. Their in-progress research found that employees using generative AI worked faster, widened the scope of what they considered their job, kept more threads alive at once, and let work leak into moments that used to function as pauses.

The study covers one company and should not be treated as a universal law. It still describes my experience with unnerving precision.

Expanded capability creates expanded appetite.

A task finishes faster, so the standard rises. A prototype becomes easier, so now the idea deserves a prototype. Research becomes cheaper, so every passing question can produce a six-page memo that somebody has to read. Agents can work in parallel, so the human becomes the person standing at the end of several conveyor belts trying to remember why any of them are running.

The machine saved time inside the task. I reinvested the savings into a larger life.

I accidentally became the manager of my own abundance

A few months ago, I built my own company Slack where everyone else is an AI agent.

The system works. Different agents have different jobs and memory. They hand off research, strategy, editorial work, and implementation tasks. Important actions come back to me for approval. Finished work leaves a record instead of vanishing into a chat window.

It gave me the capacity I wanted.

It also made something visible that had been easier to ignore when my tools were slower… I am often the bottleneck because I have refused to choose what deserves me.

Agents can research three directions at once. I still have to decide which direction becomes a commitment. They can produce options quickly. I still have to feel the difference between the interesting option and the one I am willing to live with. They can draft the launch plan, inspect the product, and surface the open questions. I still own the promise.

The work waiting for me is rarely typing now. It is deciding, reviewing, having the conversation, and owning what happens next. Sometimes it is the uncomfortable choice to let a good idea remain unrealized.

That last one is brutal.

When an idea cost a week to explore, reality killed most of them early. Now I can ask an agent to make the idea legible before lunch. It comes back with a name, a market map, a product brief, a first-pass interface, and just enough momentum to become emotionally inconvenient.

AI removed the friction that used to protect me from my own curiosity.

I do not want that friction back. I like being able to follow a question wherever it goes, from product into writing or code. That range feels closer to how my brain has always wanted to work.

But I need a new protection against the abundance.

Parallel work still creates serial judgment

The fantasy of agents is that everything can happen at once.

Research can run while code is being written. A content draft can develop while another agent inspects customer language. The system can monitor one project, prepare another, and keep a third warm in the background.

Technically, this is true.

Emotionally and cognitively, the work still returns to one single person.

Every live thread carries a small amount of unresolved weight. A report needs a decision. A draft needs an opinion. A prototype needs testing. A promising idea needs a conversation with someone who may care. A broken workflow needs diagnosis. Even the work I decline requires enough attention to decline honestly.

Microsoft called the broader workplace version the infinite workday. Its 2025 analysis described work beginning earlier, ending later, and arriving through more interruptions. AI did not create the meeting invite, the late email, or the phone vibrating during dinner. It arrives inside a work culture that was already very good at turning every available surface into somewhere work could happen.

Agents add another layer. They keep working after I stop looking.

That can feel magical until I return to five thoughtful outputs, three decisions, two errors, and one agent that has misunderstood a sentence with the confidence of a consultant billing by the hour.

The queue moved faster than I did.

This is the part I missed. I pictured myself doing the same amount of work with less effort. I did not picture myself becoming capable of caring about more work than a day can hold.

Capacity needs a budget

I used to think the answer was a better system.

Then I built a system for nearly everything and watched New York keep ruining it. The useful lesson was not that systems fail. It was that a system should serve a life with weather, other people, changing desires, and the occasional decision to walk twenty blocks because the city looked good.

The same is true here.

A good system can help me do more. It cannot decide that more is enough.

That decision needs a budget. Not a time-management spreadsheet with every bathroom break turned into a quarterly initiative. A budget for what I am willing to keep alive.

Here is the version I am trying now.

The Leverage Budget

For every meaningful AI workflow, agent, or new project, I answer five questions.

1. What work did this remove?

Name the hours, delay, cost, or frustration that disappeared. If the system only created a new stream of outputs to supervise, it may have increased capacity in theory while reducing it in practice.

2. What new work did it create?

Count review, correction, tool maintenance, approvals, follow-up, and the ideas that became possible because the first output arrived quickly. The second-order work is still work.

3. What can only I do now?

Usually this is a decision, a conversation, a judgment call, a promise, or a refusal. Put that work on the calendar before starting another machine task. Otherwise the system keeps generating ingredients while the kitchen has no chef.

4. What will I stop keeping alive?

Every new recurring workflow or serious project needs a subtraction. Archive something. Pause something. Narrow the promise. Let a decent idea remain decent and unrealized.

This is not punishment. It is how the chosen work gets enough of me to become good.

5. What would enough look like this week?

Define the stopping condition before the tools make another round of improvement feel cheap. One published essay. One product decision. One customer conversation. One tested workflow. One evening where nobody, including the synthetic employees, gets to brief me.

The point is not to cap ambition at a polite level.

It is to stop confusing available capability with required commitment.

I need stronger selection

I still want the tools.

I want agents doing research while I sleep. I want to build products across disciplines I was never formally trained in. I want a question from a meeting to become a source-backed decision before the context disappears. I want one person with taste and responsibility to be able to do work that used to require a small company.

The capability is astonishing.

My mistake was assuming that capability would feel like free time.

It feels more like standing in front of several open doors and realizing the hard part is no longer getting through one. The hard part is accepting that walking through every door is another way of going nowhere.

AI can multiply attempts and produce drafts, research, or prototypes quickly. It can lower the cost of finding out whether something might work.

My time still goes where my life goes.

That makes selection the human work beneath all of this. Choosing which artifact deserves completion. Which conversation deserves presence. Which project deserves the slow parts after the exciting first burst. Which possible version of myself is allowed to become a real obligation.

I am not out of time because AI failed to make me faster.

I am out of time because it made more of my ambition executable.

The next improvement is not another agent.

It is becoming a little harder to impress with possibility.

Reply and tell me: what has AI made possible for you that you may need to stop keeping alive?

-zc

P.S. If you want practical notes on using AI without turning your entire life into a backlog, subscribe to Don’t Feed The Algorithm.

Subscribe now

The robots are fast. We are attempting to remain people.

Rabbit hole for the overcaffeinated

- UC Berkeley Haas on AI and work intensification: An accessible summary of an eight-month ethnographic study showing how expanded capability can widen scope and dissolve stopping points. The research is still in progress and covers one company, which is worth keeping in view.

- AI Doesn’t Reduce Work. It Intensifies It.: The Harvard Business Review article from Xingqi Maggie Ye and Aruna Ranganathan on the same research and the case for deliberate AI work practices.

- Microsoft’s “Breaking Down the Infinite Workday”: Workplace telemetry and survey evidence on work spreading across more of the day, useful context for why faster tools do not automatically create protected time.

- I Built My Own Company Slack. Everyone Else in It Is an AI Agent.: The operating system behind the abundance problem.

- I Built a System for Everything. New York Keeps Ruining it.: The earlier lesson about leaving enough room for a life to interrupt the plan.

In my recent article, I made the case for treating the new Mac Studio as a private company AI server.

This is the article for people whose immediate response was:

Cool. Sold. What do I actually buy, install, and run?

The short version is that you need more than a very expensive Mac and a downloaded model.

A usable company system has five layers:

→ Team interface

→ identity and permissions

→ shared company knowledge

→ local model server

→ logs, backups, and governance

The model is only one layer. If you skip the others, you have built a powerful local chatbot with access to sensitive company information, not a company brain.

Running inference locally can keep prompts and documents from being sent to a third-party model server, which is a real privacy benefit.[3] But that benefit disappears quickly if the interface, retrieval system, logs, or backups quietly send the same data somewhere else.

This guide lays out the first version I would build for a small company: one Mac Studio, one local model, one internal interface, a deliberately bounded knowledge base, and a small pilot group.

It is not a replacement for a security review. It is not an enterprise architecture disguised as a weekend tutorial. And it is definitely not permission to put payroll, HR files, and every customer transcript into one giant vector database on day one.

It is a practical way to find out whether the idea works before turning it into infrastructure.

Pay a systems-obsessed geek like me $8 so I can keep writing these rabbit holes and in return you’ll learn how to save your company thousands on AI costs 🤝 win win for everyone.

Read more

Let me start by saying I do not need the new Mac Studio… complete with 512GB of unified memory and an 8TB set of pretty little storage.

This is usually the point where I begin explaining why I might buy one anyway.

But Apple’s latest release created a more interesting itch than the usual faster-chip, nicer-screen, unjustifiable-purchase cycle. The company is not being subtle about what this machine is for. Apple calls the new Mac Studio “the ultimate desktop for on-device AI.” The M5 Ultra configuration can carry up to 512GB of unified memory with 1.2TB/s of memory bandwidth… enough, Apple says, to run massive language models entirely on the device.

That is an absurd amount of computing power in a box that can sit quietly on a desk.

And it made me wonder…

What if a small company treated one of these machines as its private AI server?

Not another employee with another individual ChatGPT account. Not ten disconnected copilots that know nothing about one another.

One shared reasoning system, one permission-aware company brain, and a set of interfaces the whole team could use.

A private AI operating layer that physically lives with the company.

I want to try building that.

I just might.

Apple basically released a desk-sized AI server

The new Mac Studio comes in M5 Max and M5 Ultra configurations. The Max supports up to 128GB of unified memory. The Ultra goes all the way to 512GB come October, with up to a 36-core CPU and 80-core GPU. Apple also added Neural Accelerators to the GPU cores and says prompt processing in LM Studio can be up to four times faster on M5 Ultra than on the previous M3 Ultra.

Apple announced it on August 25, opened preorders immediately, and plans to start deliveries September 22. The 512GB configuration is expected in late October.

The memory is the part that interests me most.

Large-model inference is often less about whether a processor is theoretically fast enough and more about whether the model, and its working context, can fit close enough to the compute. Apple’s unified-memory architecture lets the CPU and GPU work from the same memory pool instead of constantly moving data between separate banks. Apple’s MLX framework was built around that architecture, supports quantized models, and can run or fine-tune many models available through Hugging Face.

The new machine can also be clustered over Thunderbolt 5 using RDMA. Apple says a four-machine cluster can create a larger shared memory pool and reach up to three times the inference performance of one system.

That sounds less like a creative workstation and more like the beginning of an unusually approachable private AI rack.

The pricing still makes it a serious purchase: $2,499 to start for M5 Max and $5,499 for M5 Ultra, before the sort of memory configuration that makes this experiment especially interesting. But for a small company already paying for a pile of AI seats, usage-based APIs, separate knowledge tools, and consultants trying to connect them all, the comparison is not ridiculous.

It is at least worth doing the math.

The model is not the company brain

This distinction matters.

Installing a local LLM does not give a company shared context. It gives the company a model.

The brain would be everything around it…

- the company’s documents, product specs, customer calls, research, and decisions;

- a retrieval layer that finds the right information for each question;

- durable memory about what the team has decided;

- permissions that determine who can retrieve what;

- connectors to the tools where work actually happens;

- an audit trail showing which sources informed an answer or action.

The LLM is the reasoning engine. It is not the memory, permission model, or source of truth.

And that is the interesting part.

Today, most AI use inside a small company is fragmented by person and product. Marketing has its prompts. Product has its project. Sales has a bot trained on a different collection of collateral. The founder has six months of context trapped inside one long-running chat no one else can access.

Everyone is technically using AI. No one is using the same brain… at least not perfectly.

A local company server could reverse that. Every interface… chat, research agent, writing tool, meeting assistant, internal search… could call the same model service and retrieve from the same governed knowledge layer.

The marketing agent would understand the same product truth as the sales agent. The customer-success assistant would see the latest launch decision instead of an old deck. A new employee could ask why the company made a decision and retrieve the underlying source, not just a summary someone remembered to write.

Shared context would stop being a personal advantage and become company infrastructure.

Why local changes the tradeoffs

The obvious pitch is privacy. And, yes, that matters.

Apple’s own machine-learning team describes local inference as a way to avoid sending data to and from third-party servers, which can help protect user privacy. In a company setting, that could mean customer transcripts, internal financials, product plans, employee documents, and proprietary research do not need to leave the company’s environment every time someone asks the model a question.

That does not magically make the system secure. More on that shortly. But reducing the number of external systems that receive sensitive material is a meaningful change to the risk surface.

But control might be even more interesting.

A company could choose its models, decide when to upgrade them, define retention rules, inspect its own logs, and keep a stable version available for important workflows. If a model provider changes pricing, policies, or product direction, the company’s entire AI layer would not have to move overnight.

The part I keep coming back to is continuity.

People leave. SaaS subscriptions change. Chat histories get abandoned. The company brain should outlive any one employee or interface. A locally governed knowledge layer could preserve decisions, corrections, customer language, and operating context over time… without requiring everyone to remember which bot knows what.

And then there is cost.

Local does not mean free. There is hardware, electricity, setup, maintenance, backups, security, and the opportunity cost of somebody becoming the accidental AI administrator… $100 it’ll be me. But the economics become more predictable. The machine does not send an invoice because the team had a particularly curious Tuesday.

Apple is leaning directly into this argument, pitching on-device models as a way to work without counting tokens or worrying about rising cloud costs. That is marketing language, but the underlying tradeoff is real… variable inference spend becomes a fixed-capacity system the company owns.

Local is not the same thing as secure

This is where the fun hardware story becomes an infrastructure project.

A local model server would concentrate a huge amount of company context in one place. That makes it valuable. It also makes it a target and a potential single point of failure.

The Mac gives you a solid base. FileVault encrypts full volumes, and on Apple silicon its key handling uses the Secure Enclave. But disk encryption is only one layer.

A real company system would still need:

- individual authentication, not one shared password;

- role- and document-level access controls;

- encrypted, tested backups;

- network segmentation and a hardened gateway;

- patching and dependency management;

- audit logs for retrieval and actions;

- rules for what enters long-term memory;

- a way to revoke access immediately;

- defenses against prompt injection inside indexed documents.

Most importantly, shared context cannot mean shared access to everything.

Finance, HR, customer data, product plans, and general company knowledge should not all collapse into one undifferentiated vector database. Retrieval has to enforce permissions before context reaches the model.

NIST’s zero-trust guidance makes the underlying point clearly: a user or device should not receive implicit trust simply because it is inside the local network. “It never leaves the office” is not an authorization model.

Even the official MLX-LM server documentation warns that its built-in HTTP server is not recommended for production because it only implements basic security checks. So the easy demo… start a model, expose a port, let everyone connect… is exactly that; a demo.

The interesting work begins after the model responds.

What I actually want to build

I am imagining a deliberately small first version.

One Mac Studio. One carefully chosen local model. One internal interface. A bounded collection of company knowledge. Five or six real users.

The architecture might look something like this:

→ Employee

→ authenticated internal interface

→ permission and policy gateway

→ company brain

→ documents and customer calls

→ decisions and corrections

→ product and brand truth

→ role-specific memory

→ local model server

→ cited answer, proposed action, or refusal

→ audit log

The first use cases should be boring enough to evaluate honestly:

- preparing for a customer call;

- answering a product question from approved sources;

- turning customer language into a content or enablement brief;

- explaining why the team made a prior decision;

- synthesizing a week of product, customer, and market signals;

- finding contradictions across current company knowledge.

I would not start by letting it send emails, change production systems, or become the world’s most confident intern. First, it should prove that it can retrieve the right context, respect access boundaries, cite its sources, and admit when it does not know.

Then I would measure:

- answer quality against the cloud models people already use;

- latency when several employees ask questions at once;

- how often retrieval finds the wrong or outdated source;

- the real administrative burden;

- power and hardware costs;

- what breaks when the machine is unavailable;

- whether shared context actually changes the quality of team decisions.

The Mac Studio makes the model-serving part feel surprisingly attainable. Apple’s own tooling is moving quickly… MLX can run quantized models efficiently across Apple silicon, and the new Core AI framework is designed for deploying full-scale local models into applications.[

The rest of the system, the part that turns a model into a trustworthy company brain, is still the hard part.

That is the part I am excited about.

The company server might be coming back

For years, the default software story was simple: move everything to the cloud, rent every capability, and let someone else maintain the machines.

Generative AI complicates that story.

The most valuable input to a company AI system is the company itself: its conversations, customers, decisions, drafts, failures, and accumulated taste. That context is both sensitive and strategically useful. Sending all of it through a growing stack of external AI products may not remain the obvious default forever.

The new Mac Studio makes another model imaginable.

A small, quiet machine in the office, or a locked room, or a properly managed colocation facility, running a capable open-weight model and serving a governed brain to the company around it.

Not fully disconnected from cloud AI. Frontier models will still win plenty of tasks. Some workloads will still need elastic compute. A local server does not have to become an ideological purity test.

But it could become the private center of gravity:

- local context by default;

- external models used intentionally;

- company memory owned by the company;

- one shared brain instead of a dozen disconnected chats.

I do not know yet whether this becomes a practical small-business stack, a consulting offering, a product, or an expensive weekend project that gets wildly out of hand.

That uncertainty is mostly why I want to try it.

Apple released a very powerful computer.

I am curious whether it also released the first genuinely approachable company AI server.

Would you trust one machine with your company’s shared memory… and what is the first boundary you would refuse to cross? Reply and tell me. I am especially interested in the use case that would make this worth building for you.

-zc

P.S. If you like essays about AI systems, company-building, privacy, and staying human while the machines get alarmingly capable, subscribe to Don’t Feed The Algorithm.

Subscribe now

Rabbit hole for the overcaffeinated

- Apple’s new Mac Studio announcement — the primary source for the M5 Max and M5 Ultra configurations, local-model claims, clustering, pricing, and availability.

- Exploring LLMs with MLX and the Neural Accelerators in the M5 GPU — Apple’s useful technical explanation of unified memory, quantization, time to first token, generation speed, and why memory bandwidth matters.

- NIST’s Zero Trust Architecture — the less exciting but more important reminder that “it lives in our office” is not an authorization model.

- I Built My Own Company Slack. Everyone Else in It Is an AI Agent. — my earlier experiment with shared agent context, bounded roles, persistent memory, and enforced stopping rules.

- Your Employees Don’t Need to Learn AI. Their Workflows Do. — the adjacent argument for measuring changed work rather than licenses, logins, and AI activity.

When I was 15, I wrote a book.

A whole book. An aggressively unpublished book.

I sent it to literary agents because I had the confidence of a teenager and none of the useful information. They sent back rejection letters because they had standards and, presumably, eyes.

Then I started filming my friends skateboarding and snowboarding. I made what I later described as “a few crappy movies”.

This is still the most accurate critical review of my early filmography.

The book did not become a book deal. The movies did not get into Sundance. Nobody asked me to explain my creative process on a podcast.

Thank god.

I was allowed to be bad long enough to become interested.

That used to be a fairly normal way to begin. You tried something because it pulled at you. You borrowed the wrong equipment. You made a version nobody needed. You showed it to three friends, one of whom was mostly being supportive because you had driven them somewhere recently.

You did not need a launch strategy for the first evidence that you cared.

Now every new interest arrives with an audience already attached.

The feed shows you the identity before you have the practice

Decide you want to run and, within an hour, you can see the training plan, the watch, the shoes, the gels, the cold plunge, and a man with three percent body fat explaining Zone 2 from a Scandinavian kitchen.

Buy a camera and the feed immediately introduces you to photographers with fifteen years of work, perfect color, a signature preset, a sold-out workshop, and a bag that costs more than the camera you were nervously considering.

Try writing and you are shown the newsletter growth system before you have written something you would miss if it disappeared.

The internet is incredible at showing us what mastery looks like. It is less good at preserving the quiet, unremarkable stretch before mastery becomes visible.

That stretch matters.

It is where you learn whether you like the work or merely like the person you imagine becoming if the work goes well.

The feed collapses the distance between curiosity and comparison. You are six minutes into a new interest and already losing to someone who has organized their adult life around it.

So we compensate. We research harder. We buy the correct setup. We learn the vocabulary. We announce the project because public commitment is supposed to create accountability.

Sometimes it does.

Sometimes it turns a small curiosity into a performance review before it has had one afternoon to breathe.

Being a beginner used to be private by default

My early work was not private because I possessed some deep creative philosophy. It was private because distribution was f*cking annoying.

Uploading video took forever. Cameras were worse. Editing was slower. My audience was mostly friends, family, and whoever had accidentally subscribed during a more confusing period of their life.

The friction was inconvenient, but it created a useful boundary. Making and publishing were separate decisions.

Now the camera, editing suite, audience, analytics dashboard, storefront, and monetization advice all live inside the same rectangle in your hand.

This has created real opportunity. I built much of my career by becoming obsessed with the bridge between creative work and distribution. I brought a camera to the beach, started paying attention to Instagram, and eventually became more interested in the machinery of marketing than any normal person should admit in public.

I am not arguing that artists should hide forever or that distribution corrupts the work. Making something for another person can sharpen it. An audience can create stakes. Feedback can expose the difference between the thing in your head and the thing that arrived.

But an audience changes the work.

That is not always a problem. It is simply a reason to decide when the audience enters.

AI can make the beginner stage look finished

AI makes this tension stranger.

It is now possible to become presentable at something before becoming competent at it. You can generate the logo, the landing page, the launch post, the curriculum, the content calendar, and twelve tasteful mockups for a project you have spent forty-three minutes actually doing.

Again: useful. I use these tools constantly. They have helped me build products, research unfamiliar subjects, pressure-test ideas, and move from vague thought to working artifact much faster.

But speed changes what you can skip.

A rough first attempt used to reveal exactly where your hands, ears, judgment, or understanding were weak. Now AI can sand down those signals before you have looked at them.

If the first song sounds decent, the first essay reads cleanly, and the first app resembles a startup, you can mistake presentation for progress. The output looks less embarrassing. You may understand it less.

The danger is not that AI helps beginners. A patient AI tutor can make starting far less intimidating. The danger is asking it to rescue every early attempt from looking early.

Beginners need help. They also need evidence of where they are beginners.

Ira Glass described the painful distance between your taste and your current ability: you know the work is not good yet because your taste is already good enough to notice. His advice was not to eliminate that gap. It was to make a large volume of work until your ability catches up.

AI can help you cross the gap.

It can also generate a tasteful little bridge that lets you avoid seeing the gap at all.

Your first ten attempts should not have a business model

I understand the urge to ask every interest what it could become. I have spent years building systems that make work compound. I can turn a new curiosity into a folder structure before the curiosity has finished introducing itself.

This is occasionally useful and frequently a cry for help.

The moment something interests us, we ask what it could become:

Could this be content?

Could this become a product?

Could I build an audience around it?

Could it make money?

Could I become known for this?

Those are not bad questions. They are just late questions arriving early.

Austin Kleon describes a hobby as creative work that is just for you… something you do without trying to get rich or famous from it. I like that definition because it gives the activity time to affect you before you demand that it perform for everyone else.

The first job of a new practice is not to become useful.

It is to determine whether you want to return.

The Private Beginner Protocol

This is less of a doctrine and more of a 30-day protection plan for a fragile new interest. I am writing it because, frankly, I need it.

1. Choose a practice, not an identity

Do not decide to become a photographer. Go take pictures.

Do not announce that you are writing a novel. Write one page tomorrow and another the day after that.

Identity can create commitment, but it can also create a costume you start maintaining instead of a skill you are developing.

For 30 days, use verbs.

2. Do not announce the beginning

Public commitment can help with goals that already matter to you. It is less reliable when you are still figuring out whether the interest is real.

Give yourself one month without a launch post, progress thread, new bio line, or tasteful screenshot of the workspace.

Nobody needs to know yet. That is the gift.

3. Delay the expert setup

Use what you have, borrow something, or buy the smallest credible version.

I say this as a person who once promised to begin film photography with a practical camera and then [bought a Leica M3](https://www.35mmc.com/08/02/2024/falling-in-love-with-film-promising-to-not-buy-a-leica-m3-part-one/). I am aware that my authority here has been compromised.

The point is not to make deprivation part of the hobby. It is to keep shopping from impersonating practice.

4. Make ten things before asking what they are worth

Ten photographs. Ten meals. Ten sketches. Ten tiny programs. Ten pages. Ten attempts at repairing the same motorcycle part while saying words the service manual did not anticipate.

You need enough material to notice what keeps pulling you back.

Do not monetize the first attempt. Do not package the third. Do not build the course while learning lesson four.

5. Use AI as a teacher, not a body double

Ask it to explain a term, critique your attempt, suggest an exercise, or help you understand why something failed.

Do not automatically ask it to replace the part you are trying to learn.

If you are practicing writing, write before requesting a rewrite. If you are learning design, make the layout before asking for variants. If you are coding, explain what the code should do before accepting a generated solution.

Let AI shorten confusion. Do not let it remove contact with the craft.

6. Keep the ugly archive

Save the crooked photographs, dead paragraphs, bad cuts, weird color grades, broken prototypes, and ideas that seemed profound at 1:14 a.m.

Do not post them as a humblebrag carousel about “the journey.” Just keep them.

Your early work is evidence. Later, it will show you which problems disappeared through practice and which ones keep following you because they are part of your taste.

7. Invite the audience when the work needs one

After 30 days, ask:

- Do I want feedback, accountability, connection, opportunity, or simply attention?

- Would sharing help the practice continue?

- Am I showing the work, or trying to establish the identity?

- If nobody cared, would I make the next one?

Publish when the audience gives the work a useful consequence.

Keep going privately when attention would make the work smaller.

Make something that cannot help your career yet

I do not want a life where every interest becomes a business, every observation becomes a post, and every small act of curiosity has to explain its strategic value.

That sounds productive. It also sounds exhausting, man.

Some of the most useful things I know began as things I was bad at for no defensible reason. Writing a rejected book taught me to finish. Filming my friends taught me to frame and edit. Photography made me pay attention. Publishing introduced me to distribution. None of those lessons arrived because I had correctly mapped the outcome in advance.

They arrived because I stayed near the work.

Maybe the answer is not to reject the algorithm, hide every ambition, or pretend we do not care what other people think. I care. You probably care. Most people who claim otherwise are either enlightened or lying, and I have met fewer of the first group.

The answer may be simpler.

Protect the beginning.

Give the new thing a little time before you ask it to become impressive, legible, profitable, or public. Make a few bad versions. Let your taste hurt your feelings. Return anyway.

You are not behind.

You are beginning.

What is something you would try if you were allowed to be bad at it privately for 30 days? Reply and tell me. I am looking for ideas that have not hired a growth team yet.

-zc

P.S. If this made you want to protect one strange little interest from the feed, subscribe to Don’t Feed The Algorithm. That is more or less the entire assignment around here.

Subscribe now

Rabbit hole for the overcaffeinated

- Ira Glass on the taste gap

— The classic explanation of why good taste often makes early creative work feel especially painful.

- Austin Kleon in praise of the good old-fashioned hobby — A useful defense of creative work that gives without needing to become a career.

- The Creative Independent guides — Practical, emotionally intelligent advice from working artists without much productivity cosplay.

- Stanford’s guide to growth mindset — A compact primer on treating early failure as information rather than identity.

- Wanting Things Without Irony — A related argument for admitting what you want before self-awareness turns into camouflage.

- The Internet Is Full of Correct Answers. I Miss Opinions. — On why access to endless polished answers does not replace developing a point of view.

I was reading the Montréal Declaration on Responsible AI this week, which is a sentence that makes me sound more emotionally stable than I was while doing it.

I had more browser tabs open than any ethical framework could reasonably justify, and the growing suspicion that every interesting AI question eventually becomes an ethics question wearing a product roadmap.

One line kept bothering me.

The declaration says AI systems should contribute to a just and equitable society. It also says they should be intelligible, justifiable, accessible, and compatible with social and cultural diversity.

All good. Hard to oppose without twirling a small villain mustache.

But I kept thinking about a quieter problem.

What happens when AI does not make the final decision, but decides who gets considered in the first place?

We are moving from a web where people search through options to one where AI systems increasingly synthesize and recommend them. [OpenAI now describes ChatGPT shopping as a place where people can compare options and figure out what to buy. Its commerce protocol is designed to ingest structured merchant data, understand inventory, and surface relevant products in context.

That sounds like a shopping feature.

It is also a preview of a much larger shift.

The agent does not need to reject you. It only needs to build a reasonable shortlist without you on it.

The new gate can appear before the visit

For most of the commercial internet, visibility worked roughly like this:

→ Search

→ list of links

→ human visits a few

→ human compares

→ human chooses

That process was never perfectly fair. Search rankings concentrated attention. Advertising bought access. Large brands accumulated links, reviews, data, and familiarity that smaller organizations could not manufacture on command.

But the options were at least visible as options.

The emerging version looks more like this:

→ Human states a need

→ AI interprets the need

→ AI retrieves evidence

→ AI assembles candidates

→ AI compares the candidates

→ human sees a compressed answer

I have written before that your next buyer might meet you as a shortlist before they meet you as a website. The more I sit with that shift, the less it feels like an SEO problem.

It is an access problem.

A small manufacturer may make the best object for a particular buyer but have incomplete product data. A local nonprofit may be unusually effective but explain its outcomes inside a PDF last updated by someone who has since moved to Vermont. A specialist consultancy may have deep expertise but little third-party coverage. A new company may solve the problem cleanly while an older competitor owns ten years of backlinks, reviews, comparison pages, and machine-readable proof.

The machine is not necessarily hostile to any of them.

It may simply have more usable evidence for someone else.

That distinction matters because legibility is not merit.

Legibility is the ability to be found, understood, compared, and justified by a system. Merit is whether you are actually good, relevant, trustworthy, useful, or right for the person asking.

They overlap.

They are not the same thing.

The internet has always rewarded the well-documented

This is not an argument that AI invented inequality.

The old web was already easier for organizations with money, links, technical teams, strong distribution, and enough content to occupy every possible question. Search optimization has always favored people who knew how the system worked… or could at least afford to hire someone who did.

The difference is compression.

Ten blue links still allowed a person to wander, ignore the first result, notice an unfamiliar name, open six tabs, distrust all of them, and eventually text a friend.

A synthesized answer can do more of that work before the human arrives.

That is useful. I do not want to return to manually comparing 37 nearly identical product pages while each one announces that it is “revolutionary.” I would happily delegate more research to a system that understands my budget, constraints, taste, and unreasonable emotional relationship with objects made of old metal.

But convenience changes the location of the gate.

If the system retrieves only a narrow set of candidates, the user cannot evaluate the options that never entered the answer. The shortlist becomes an invisible border around the decision.

This is why machine-readable proof matters. Clear product records, current pricing, structured details, explicit fit, credible evidence, third-party sources, and dated claims give an AI system something it can use.

That is good marketing advice.

It is not yet an equitable information system.

We should not pretend the evidence is settled

There is an easy version of this article where I declare that AI recommendations automatically favor the biggest brands, cite one alarming chart, and spend the rest of the essay looking concerned near a graph.

The research is more complicated.

One recent audit of generative search in the Web3 domain found that larger follower bases and more concentrated creator networks were associated with higher-ranked citation exposure. The authors warn that this could entrench prominent voices, but they are also explicit about the limits: one domain, an external prominence metric, API-versus-interface differences, and exposure estimates rather than observed user behavior.

A broader study of generative search found something that cuts against the clean doom story… across several systems, generative engines often cited less-popular domains than organic search. The exact pattern changed by engine and dataset.

And a 2026 critical survey of 45 GEO studies concluded that the field still has inconsistent terminology, metrics, and evidence standards. Visibility depends on multiple partially observable stages: whether search activates, what gets crawled, what gets retrieved, where a source appears in context, whether it is cited, whether its information shapes the answer, and what the user eventually does.

In other words… we do not have enough evidence to say AI-mediated discovery always entrenches incumbents.

We have enough evidence to know the question is real.

That is the more honest boundary.

The point is not to announce that every small organization is being erased by a robot concierge. The point is that systems are beginning to mediate consideration at scale, and we still do not have mature ways to inspect who repeatedly disappears, why they disappear, or whether absence reflects poor fit, missing evidence, popularity, technical inaccessibility, stale information, or a flaw in the retrieval system.

A reasonable answer can still produce an unreasonable pattern.

AI legibility is becoming a form of opportunity

This is the idea I cannot shake:

In an AI-mediated market, legibility becomes access to consideration.

Not guaranteed selection. Not guaranteed revenue. Not proof that the organization deserves to win.

Consideration.

The chance to enter the set of options that a person, buyer, donor, applicant, patient, student, or partner may evaluate.

That is why I think we need a concept I am calling AI Legibility Equity:

Legitimate organizations should have a fair chance to be accurately understood and considered by AI systems without needing the resources to manufacture an overwhelming volume of machine-readable authority.

There are two responsibilities hiding inside that sentence.

The first belongs to organizations.

If the facts about you are vague, stale, contradictory, inaccessible, or trapped inside a beautiful page that only makes sense when viewed as a whole, the system has less to work with. You cannot demand accurate representation while treating product truth like a scavenger hunt.

The second belongs to the systems doing the selecting.

They should not quietly treat popularity as quality, documentation volume as legitimacy, or missing machine-readable evidence as proof that an organization is irrelevant. They should expose sources, preserve uncertainty, distinguish absence from poor fit, and make consequential recommendation patterns possible to audit.

The Montréal Declaration gives us useful language for this: intelligibility, justifiability, equity, diversity, inclusion, prudence, and human responsibility. UNESCO’s AI ethics recommendation similarly treats inclusion, justice, diversity, access to information, and the digital divide as part of the ethical surface of AI.

Those principles should not begin only after an AI system makes a dramatic decision.

They should apply to the quieter decisions that shape the menu.

The Legibility Equity Test

If you build, buy, audit, or market through an AI system that recommends people, products, organizations, services, sources, or opportunities, ask these seven questions.

1. What had to be true to enter the candidate set?

Could the system consider only organizations with structured feeds, certain review volumes, strong domain authority, approved integrations, or coverage from a known group of sources?

The rule may be technically reasonable. Make it visible anyway.

2. Does absence mean bad fit, or missing evidence?

Those are different states.

A company may be wrong for the user. It may also be relevant but poorly documented, inaccessible to the retrieval layer, newly launched, geographically underrepresented, or described in language the system did not connect to the request.

Do not flatten every absence into irrelevance.

3. Can the system explain why each option appeared?

Not with “AI-generated recommendations may be inaccurate.”

What evidence mattered? Which constraints were used? Which source established the feature, price, qualification, location, or outcome? What information was missing?

A shortlist without a reason is a ranking wearing conversational clothes.

4. Are popularity and proof being confused?

Popularity can be evidence of familiarity, adoption, or social trust.

It can also be the result of age, budget, distribution, existing privilege, or being very good at publishing comparison pages about yourself.

Ask whether the system can recognize credible smaller sources, original evidence, domain expertise, and strong fit without treating raw volume as merit.

5. Is there a correction path?

Can an organization update stale information, dispute a false claim, expose a current source, or understand why its record is incomplete?

If machine-readable reality becomes consequential, correction cannot depend on winning a support-ticket séance.

6. Who keeps disappearing?

One reasonable answer proves very little.

Audit patterns across repeated queries, locations, languages, buyer stages, constraints, and user profiles. Look at who is retrieved, cited, named, compared, recommended, and omitted. Preserve the denominator. Separate what the system could not find from what it evaluated and rejected.

Fairness lives in the distribution, not the demo.

7. Where does the human regain agency?

Can the user inspect alternatives, broaden the search, change the criteria, see uncertainty, or choose outside the generated set?

The goal is not to make the machine choose correctly on humanity’s behalf.

The goal is to help people make better decisions without hiding the shape of the choice.

Better records, better systems, wider doors

There is a temptation to treat all of this as another optimization game.

Publish more. Add schema. Create comparison pages. Feed the machine. Become impossible to ignore.

Some of that is useful. Organizations should make their truth easier to find. They should maintain current product records, publish evidence, clarify fit, and give both humans and machines accurate material to work with.

But if the answer to unequal machine visibility is simply “everyone should become better at GEO,” we will reproduce the old internet with fewer visible links and more confident summaries.

The organizations with the most money will hire the most sophisticated teams to manufacture legibility. The people already fluent in the system will compound their advantage. Everyone else will be told the algorithm found the best options.

I want a better bargain.

Organizations should earn consideration with clear, current, credible evidence.

AI systems should make the conditions of consideration inspectable.

And humans should retain enough visibility into the process to notice when a convenient shortlist has quietly become the whole world.

That is not anti-AI.

It is taking AI seriously enough to ask what happens before the answer reaches us.

Reply and tell me: where do you already see AI narrowing the set of options before a person gets to choose?

-zc

P.S. If you want more practical essays on AI, human judgment, startup marketing, and the strange systems forming underneath modern work, subscribe to Don’t Feed The Algorithm.

Subscribe now

Rabbit hole for the overcaffeinated

- The Montréal Declaration on Responsible AI — ten principles for responsible AI, including intelligibility, equity, diversity, inclusion, prudence, and human responsibility.

- UNESCO’s Recommendation on the Ethics of Artificial Intelligence — a broader normative framework connecting AI to human rights, inclusion, access to information, and the digital divide.

- When Attention Becomes Exposure in Generative Search — a useful domain-specific audit of citation exposure and prominence, with unusually clear limitations.

- Characterizing Web Search in the Age of Generative AI — important counterweight to the simple incumbent-dominance story; generative systems sometimes surfaced less-popular sources than organic search.

- Optimizing Visibility in Generative Engines: A Critical Survey — the best current reminder that visibility is multistage, stochastic, and not reducible to one score or universal trick.

- Your Next Buyer Might Be a Shortlist — my earlier essay on the shift from search results to AI-mediated shortlists.

- The Agent-Readable Content Checklist — the practical companion for making evidence easier to retrieve without turning your writing into bot bait.

Years ago, a friend handed me a Canon AE-1 over beers at a Thai restaurant on the Upper East Side. It was mechanical, simple, and slightly annoying. You had to load the film correctly, set the exposure, focus with your own hands, and decide whether the frame was worth one of the limited shots on the roll. Then you waited to find out whether you had made a photograph or preserved 1/60th of a second of your thumb.

I absolutely f*cking loved it.

This was objectively inconvenient. I already owned digital cameras that were faster, more flexible, and significantly less committed to publicly documenting my mistakes. Film did not solve a capability problem. It changed my attention. The camera asked more of me, which made me bring more of myself to it.

I had felt the same thing with my old air-cooled Ducatis.

Later motorcycles were smoother, easier, and better behaved. The older machines had heat, vibration, mechanical opinions, and a tendency to turn a calm ride into an active negotiation.

I am aware that “my motorcycle was inconvenient in a spiritually enriching way” is the kind of sentence that causes reasonable people to stop inviting you to dinner. But there was something real underneath it. It’s difficult to explain.

Some tools remove difficulty and expand what we can do. Others remove difficulty and quietly remove us from the experience. AI is forcing that distinction into almost every kind of work.

We have treated all friction like a bug

Modern product design taught us to hate friction… fewer clicks, faster checkout, one-tap signup, automatic sync, instant answers, zero setup. Do not make me think.

Most of this is good.

I do not miss copying data between spreadsheets, reformatting the same document for six channels, searching twelve folders for the approved logo, or spending half a day learning that one invisible space broke a deployment. There is no moral beauty in administrative sludge.

AI can remove extraordinary amounts of that waste: summarize the meeting, clean the dataset, draft the boilerplate, inspect the repository, compare the options, turn notes into a brief, and help a person make something they could not have made alone.

I use it for all of those things. Enthusiastically. Sometimes with enough orchestration that my laptop resembles a small bureaucracy that has recently discovered YAML.

But “remove friction” has become such an automatic product virtue that we rarely ask what the friction was doing. Some friction is dead weight. Some is a guardrail, practice, feedback, or the moment you are forced to decide whether you actually mean what you are about to do.

Remove all of it and the system becomes easier to operate. The person operating it may become less present, less skilled, or less responsible.

The goal should not be zero friction.

The goal should be intentional friction.

A tool can make the action easier and the judgment harder

The obvious story about AI is that it makes difficult work easier. The more interesting story is that it moves the difficulty.

Writing the first draft gets easier. Knowing what deserves to be written gets harder.

Producing ten product concepts gets easier. Choosing the one worth two years of your life gets harder.

Generating a polished strategy gets easier. Knowing whether it touched reality gets harder.

Building an app gets easier. Understanding what the generated code can break still matters.

I wrote about this after using Claude Code to ship software without pretending that faster implementation had magically granted me an engineering career. The machine changed what I could direct. It did not remove my responsibility for the product, the risk, the proof, or the release.

That pattern keeps showing up… AI removes production friction and increases the importance of selection friction.

When output was expensive, effort filtered ideas automatically. You could not make every campaign, prototype every product, test every positioning angle, or publish every passing thought. Cost forced choice.

Now the machine can make all of them. This feels like abundance until you become the person standing in front of 47 competent options with no idea which one contains a point of view.

Convenience did not remove the decision.

It exposed it.

The friction was carrying information

A roll of 35mm film gives you a small number of exposures. That constraint changes behavior before the shutter clicks. You look longer. Move your feet. Wait. Decide whether the light, person, gesture, or building is worth preserving.

Digital photography lets you shoot almost without consequence. That freedom is enormously useful. It also means selection often happens later, inside a folder containing 684 images from one afternoon and a growing suspicion that your actual hobby is file management.

Neither medium is morally superior. They place the judgment in different locations.

Film puts more judgment before capture. Digital allows more experimentation during capture and demands more judgment during editing.

AI does something similar with knowledge work… it moves effort from production toward direction, evaluation, and responsibility.

The danger is not that the work became easier.

The danger is failing to notice where the hard part went.

If drafting takes five minutes instead of five hours, the saved time should not automatically become nine more drafts. Some of it should move into source quality, customer contact, sharper decisions, testing, editing, and the nerve to delete what does not deserve to exist. That is why the first draft is not the work anymore. The draft is increasingly cheap material. The work is deciding what it is for, whether it is true, what it refuses, and whether it should survive.

Four kinds of friction

I have started sorting friction into four categories. Not because life needed another four-box framework, but because “make it easier” is no longer a sufficiently intelligent instruction.

1. Dead friction

Dead friction consumes time without improving the result or the person: copying information between systems, fixing formatting, hunting for files, repeating context the company should have preserved, clicking through five screens to perform a reversible action, or waiting because two tools refuse to speak to each other.

Automate this aggressively.

No one becomes wiser because the expense report required three browser tabs and a PDF that opens at 73% zoom.

2. Protective friction

Protective friction slows an action because the consequence matters: approval before publishing, a second set of eyes on a public claim, confirmation before deleting customer data, a test before deployment, or a pause before sending an emotionally ambitious email at 11:47 p.m.

This friction can be reduced, clarified, and intelligently routed. It should not be silently removed.

A review gate that never changes an outcome is theater. A review gate that catches expensive mistakes is part of the product.

3. Developmental friction

Developmental friction builds skill, judgment, or understanding. You write the argument before asking AI to improve it, solve a few examples by hand before automating the analysis, read the primary source instead of only the summary, take the photograph instead of spraying the scene, or debug enough of the failure to understand what the system misunderstood.

Psychologists Robert and Elizabeth Bjork use the term desirable difficulties for learning conditions that can make practice feel harder while improving long-term retention or transfer.

The important word is desirable.

Difficulty is not automatically educational. Sometimes the software is merely badly designed. But when the effort creates retrieval, comparison, feedback, or a more accurate mental model, removing it may improve immediate performance while weakening future capability.

4. Meaning-making friction

Meaning-making friction creates attachment because effort, attention, and choice become part of the experience… learning a mechanical camera, cooking for people instead of ordering, repairing something worth keeping, writing a letter by hand, riding a machine that asks for technique, or making a piece of work slowly enough that it begins to contain your judgment.

This category is the easiest to mock because it can slide into nostalgia cosplay very quickly.

Not every difficult object has a soul. Some are just badly engineered and expensive.

The test is whether the friction creates a quality you value: attention, mastery, character, memory, authorship, or care. If it does not, remove it. If it does, be careful what you optimize away.

Convenience can create distance

There is a particular feeling that comes from producing something faster than you can form an opinion about it. The AI draft appears. The deck is polished. The code runs. The image looks plausible. The answer is organized into five tidy bullets.

You are impressed before you are involved.

That is useful when the output is disposable. It becomes dangerous when the output represents your judgment.

The distance shows up in small ways. You approve language you would not have chosen because revising it feels slower than accepting it. You ship a feature you cannot explain because the prototype works. You forward a summary without reading the source. You publish a point you do not really believe because it arrived dressed for work.

The machine did not deceive you.

It made disengagement convenient.

This is why my best AI workflows contain places where I have to re-enter the work: approve the brief, choose the claim, inspect the evidence, reject the recommendation, run the user path, decide what can become public. Those moments are not failures of automation. They are where authorship returns.

If this distinction is useful, subscribe. I keep writing about the part of AI work that begins after the demo looks impressive.

The friction audit

Before automating a difficult step, ask:

1. OUTCOME

What becomes better if this step disappears?

Faster completion, lower cost, fewer errors, broader access, or less cognitive load?

2. SIGNAL

Does the friction reveal anything important?

Intent, understanding, quality, risk, commitment, fit, or readiness?

3. SKILL

Does doing this build a capability I still need when the tool fails,

the stakes rise, or the context changes?

4. CONSEQUENCE

Is the pause protecting a public claim, customer, deployment, payment,

sensitive decision, or irreversible action?

5. FEEDBACK

Does the effort bring me into contact with reality?

A customer, source, failure, material, place, or physical result?

6. ATTACHMENT

Does the difficulty create attention, memory, mastery, authorship, or care?

Or am I romanticizing inconvenience because it photographs well?

7. RELOCATION

If AI removes the effort here, where does judgment need to move?

Direction, selection, verification, editing, approval, or reflection?

Then choose deliberately:

DELETE dead friction.

AUTOMATE repeatable friction.

ENFORCE protective friction.

PRACTICE developmental friction.

PRESERVE meaning-making friction.

RELOCATE judgment when production gets cheap.

The final line matters most.

Every time a tool makes one part of the work effortless, ask where the responsibility went.

If the answer is nowhere, you may not have removed friction.

You may have removed attention.

I still want the easier tools

This is not an argument for returning to typewriters, paper maps, manual deployments, or motorcycles that need emotional reassurance before starting. I like modern tools. I like autofocus. I like software that anticipates the next action. I like AI systems that compress hours of administrative work into minutes and make previously impossible projects available to one person.

Capability matters. Access matters. Convenience can be humane.

The mistake is assuming the ideal experience asks nothing of us.

The best tools I have used do not maximize effort, but they leave the meaningful decisions visible. They remove the parts that waste attention and sharpen the parts that deserve it.

A good camera can make exposure easier without deciding what is worth seeing.

A good coding agent can make implementation faster without deciding what should ship.

A good writing system can make a draft cheaper without deciding what you believe.

A good product can reduce friction without reducing the user to a passenger.

Years ago, after that Upper East Side dinner and an entirely reasonable plan to buy an inexpensive film camera, I bought a Leica M3. It was not the practical choice. It was tactile, purposeful, subtle, and demanding enough to make every photograph feel like an act rather than an event that happened near me.

The camera did not make the image good.

It made it harder for me not to be there.

What is one piece of friction in your work or life that you would never automate away? Reply and tell me what it gives you in return.

-zc

P.S. If you want more essays about AI, taste, work, and preserving the human parts without pretending old tools were universally better, subscribe to Don’t Feed The Algorithm.

Subscribe now

Rabbit hole for the overcaffeinated

- Robert and Elizabeth Bjork’s Learning and Forgetting Lab — the research home for desirable difficulties, retrieval, spacing, and why easier practice is not always better learning.

- Matthew B. Crawford’s Shop Class as Soulcraft — a philosophical argument for skilled manual work, material feedback, and the intelligence embedded in making and repairing.

- Nicholas Carr’s The Glass Cage — an examination of automation, skill, disengagement, and how technology can expand human experience without quietly narrowing it.

- Falling in Love With Film and Promising Not to Buy a Leica M3 — my original, slightly less restrained account of the camera story.

- The First Draft Is Not the Work Anymore — the practical writing version of the same shift: when production gets cheap, judgment becomes the job.

The other day I wrote about [the test I would make Grok Bot pass before hiring it as a $200 AI coworker.

Today I want to do the more dangerous thing.

I want to show you how I would use it to build a company.

Not a billion-dollar company assembled over lunch while you sit near a pool and receive tasteful Slack notifications from your digital executive team. The internet has generated enough images of that person already. He appears rested. I do not trust him.

I mean a lean one-person company built around one customer, one painful problem, one paid outcome, and a small group of agents that can research, organize, build, draft, check, and remember work while you remain responsible for the decisions.

The promise is not passive income.

The promise is that one motivated person can stop waiting for the perfect cofounder, a giant seed round, an engineering department, or a calendar with more emotional availability.

You can finally put the idea in contact with reality.

First, the honest product boundary

Grok Bot is in early beta. SpaceXAI says each user gets a persistent cloud computer where Bots can sign into apps and websites, work while your laptop is closed, remember prior work, save demonstrated workflows as routines, and coordinate with other Bots in shared threads.

It is currently available to Cursor Ultra, SuperGrok Heavy, and Cursor Premium Teams subscribers. Cursor Ultra is listed at $200 per month, while Premium Teams is listed at $120 per seat per month. The subscription includes weekly usage; additional usage can be billed based on token cost.

There is one detail you need to understand before naming a Bot “Chief Financial Officer” and handing it the routing number.

All of your Grok Bots share one persistent cloud computer.

They share files, browser state, and logins. The Bots may have different jobs, but their names are not security boundaries. If one Bot can reach an account on that machine, assume the others may be able to reach it too.

That changes how I would set up the company:

- dedicated startup accounts rather than your entire personal life;

- the least access needed for the current job;

- drafts before sends;

- staging before production;

- no banking, binding contracts, payroll, taxes, customer secrets, destructive actions, or production releases without human control;

- promotion only after the Bot completes a probation period with evidence.

One more disclosure: I have not run this exact Grok Bot company system end to end. The setup below is a designed implementation blueprint based on my own agentic setup and SpaceXAI’s current product materials, the one-person-company system I already use around AI agents, and the failure modes I have experienced while building real products with agentic tools.

The onboarding interface will change. The management contract should survive it.

What you are actually building

A one-person AI company is not one person pretending 14 chat windows are employees.

It has five layers:

FOUNDER

Direction, customer contact, taste, risk, final approval

COMPANY BRAIN

Customer, offer, product truth, proof, current state, permissions

CHIEF BOT

Turns goals into jobs, routes work, tracks state, escalates decisions

SPECIALIST BOTS

Customer Research / Product Builder / Growth & Sales

OPERATING LOOPS

Discover → work → verify → save state → repeat or stop

The founder is not removed from the diagram.

You decide which problem matters, speak with customers, choose the promise, approve public claims, review the product, make spending decisions, handle legal and financial obligations, and decide what reaches another human being.

The Bots make the distance between those decisions dramatically shorter.

Below the paywall is the complete starter system:

- the seven company files to create before hiring the Bots;

- the exact charter for a Chief Bot and three specialists;

- the shared-computer permission model;

- the group-chat handoff contract;

- five recurring company routines;

- the ten-case probation and autonomy ladder;

- a 30-day idea-to-customer plan;

- a filled example showing how an idea becomes an offer before it becomes software.

The goal is not to make your startup look like a company.

The goal is to make it perform one complete company loop:

Find a real problem → offer an outcome → deliver it → collect proof → improve the system.

Read more

When I was 15, I wrote a book.

An entire novel.

I packaged it up, sent it to publishing agents, and received the kind of rejection letters that make perfect sense in retrospect but feel like a clear administrative error when you are 15 and have recently completed a masterpiece.

Nobody asked me to write it.

A few years later, I started filming my friends skateboarding and snowboarding. I made what I later described, with the clarity granted by distance, as “a few crappy movies.”

Nobody asked for those either.

There was no audience strategy. No content pillar. No monetization path. No little box in Notion explaining the business objective.

I wanted to make something, so I f*cking did.

This is an incredibly normal way to begin a creative life. It is also an impulse adulthood becomes strangely good at beating out of you.

Every idea eventually gets called into a meeting

Professional life rewards usefulness.

A project needs an audience. The audience needs a problem. The problem needs an outcome. The outcome needs a metric. The metric needs a dashboard. The dashboard will need a meeting, presumably so several adults can look at the same number and experience different emotions.

This is not entirely bad.

Learning to make useful things changed my life. Client work taught me to finish. Marketing taught me to care whether an idea reached another person. Product work taught me that intention is not the same as behavior. Building companies taught me that a thing can be beautiful, intelligent, and completely irrelevant if nobody needs it.

Constraints made me better.

But useful work has a side effect… eventually every private curiosity is asked to present a business case before it is allowed to live.

A photograph becomes a post.

A trip becomes a recap.

A weird idea becomes a startup.

A hobby becomes a personal brand.

A personal essay becomes a lead-generation asset about the future of authentic storytelling.

Nothing is permitted to remain itself.

Everything has to become content about becoming content.

I did not become creative because I had a strategy

The neat version of my career would say I was a filmmaker, became a marketer, moved into startups, and eventually started building products.

The real version is far messier.

Writing came first. Then cameras. Then making films with friends. Then a small production company and real client work. Then I brought a camera to the beach, became obsessed with Instagram, and became equally obsessed with the analytics behind why some things traveled and others disappeared.

Creativity and distribution were braided together early. By 2017, I was publicly describing myself as a photographer, filmmaker, entrepreneur, and digital marketer because apparently choosing one identity felt unnecessarily restrictive. Looking at my Linkedin profile in 2026 it’s clear I have yet to break that habit.

Nonetheless, the useful work did not replace the creative work. It grew out of it.

That distinction matters.

I did not start making because I had identified a high-value audience problem. I found valuable problems because making taught me to notice, select, sequence, finish, publish, and watch what happened next.

The pointless work developed the person who could later become useful.

Uncommissioned does not mean unserious

Some of the work I care about most began without a brief.

I made a cinematic short from a winter in the Tetons because the mountains were there and I wanted to learn what I could make from them.

I filmed New York and the Outer Banks over a summer while learning a camera’s color science.

Before my wedding, I wandered Florence and later turned an ordinary afternoon into a short film.

My wedding and honeymoon became another film built around the feeling of slow days in Italy.

These projects had constraints. They required equipment, judgment, editing, color, music, patience, and the deeply glamorous experience of watching the same eight-second clip 40 times because something about the cut felt wrong.

They were not casual.

They were uncommissioned.

That is different.

A commissioned project begins with an obligation to somebody else. An uncommissioned project begins with attention. You noticed something. You cared long enough to stay with it. You made a standard before there was a stakeholder available to approve it.

Nobody asking is not permission to make the work badly.

Sometimes it is the reason the standard can become fully yours.

The internet teaches us to interrogate an idea too early

The current creative stack is unbelievable.

You can write, design, code, compose, film, edit, publish, and distribute from devices you already own. AI can help you move through unfamiliar disciplines before you have earned the traditional title associated with them. The distance between “I wonder if…” and a real artifact has entirely collapsed.

This should have produced an explosion of weird personal work.

It has.

It has also produced an explosion of people asking what niche the weird personal work belongs to.

We have become very good at evaluating an idea before making enough of it to understand what it is.

Who is this for?

Can this monetize?

Will the algorithm reward it?

Does it reinforce my positioning?

Could this become a recurring format?

Should I capture emails?

These can be excellent questions on day 30.

On day one, they can kill the exact thing that made the idea even worth following.

A curiosity often arrives without language for its own value. That is why you have to make some of it. The artifact tells you what the idea was trying to become.

Paul Graham makes a related point in How to Do Great Work… the way to figure out what to work on is by working, and we should not let “work” mean only what other people tell us to do.

You cannot research your way into every conviction.

Some opinions need to be made before they can be stated.

The hidden value of useless work

Calling a project “useless” is intentionally unfair.

Uncommissioned work produces all kinds of value. It just refuses to specify which kind in advance.

It can train attention.

Photography taught me that the frame is as much about refusal as inclusion. The image changes based on what you decide does not belong.

It can train sequence.

Filmmaking taught me that individually beautiful moments can still produce a terrible story if they arrive in the wrong order.

It can train completion.

A finished bad film teaches more than an immaculate folder of references for the good film you plan to make once life becomes less busy, which historically should happen around never.

It can train taste.

When there is no client brief, trend report, or conversion rate to hide behind, you have to decide whether something feels right. Then you have to survive the possibility that your judgment was not as advanced as your self-concept.

It can train identity.

I wrote previously about wanting things without irony. Making something nobody requested is one of the clearest ways to practice it. You cannot blame the assignment. You chose the subject, the standard, the effort, and the risk of caring in public.

The project may eventually become useful.

It may lead to a job, a company, a customer, a friendship, an audience, or a new way of seeing the work you already do.

Mine did.

But if you demand that outcome before beginning, you have replaced curiosity with speculation.

You are no longer making the thing.

You are trading imaginary futures on it.

The Nobody Asked Test

I am not arguing that every adult should abandon their obligations and begin an experimental feature film in the kitchen. Rent remains famously resistant to artistic intent.

The project can be small.

The point is to protect one space where usefulness is allowed to arrive late.

Before you start, ask five questions (you didn’t really think I’d get through an entire article without assigning a task, did you?):

1. Would I still care if this never performed?

This does not require secrecy. You can publish it.

It means the work has a reason to exist before the response appears.

If the only interesting part is how people might react, you may be planning distribution rather than making.

2. What am I curious enough to learn by doing?

Choose a question that cannot be fully answered in a notes app.

Can I make New York feel like this?

Can I build a tool that behaves this way?

Can I write about this memory without sanding off what made it strange?

Can I learn this camera, material, instrument, or form well enough to express an opinion through it?

The project is an experiment, but the experiment should produce an artifact.

3. Is it small enough to finish before I explain it to death?

A three-minute film can be complete.

A ten-photo sequence can be complete.

A tiny application can be complete.

A short story can be complete.

The goal is not to begin an expansive new identity. It is to make one thing real.

4. What constraint will give it character?

One camera. One afternoon. One neighborhood. One roll of film. One page. One material. One week.

Constraints prevent uncommissioned work from becoming vague private ambition. They replace the missing brief with a shape you chose.

A project with no client still needs an edge.

5. Can I delay extracting value until the thing exists?

Do not announce the series before completing the first piece.

Do not design the course while learning the skill.

Do not build the content strategy around the hobby before discovering whether you like the hobby.

Do not turn the making-of into more work than the work.

Finish first.

Then decide whether it wants an audience, a business model, a sequel, or a quiet place on your hard drive.

Make something with no stakeholder, not no standard

The phrase “nobody asked for this” is usually delivered as an insult.

Good.

There should still be work in your life that cannot point to a committee, customer ticket, market report, content calendar, or optimized funnel as the reason it exists.

Not because usefulness is beneath you.

Because usefulness is downstream of capacities that need somewhere to develop before the market knows what to request.

Attention.

Curiosity.

Taste.

Patience.

The willingness to be bad privately and specific publicly.

The ability to follow a feeling before it becomes a thesis.

I still care deeply about making useful things. I love a real customer, a sharp constraint, a measurable result, and the undeniable satisfaction of watching something work outside my head.

I also know that the person capable of doing that work was shaped by a long trail of things nobody asked him to make.

A rejected book.

Crappy skate films.

Cameras gathering sand on beaches.

Ordinary afternoons cut into sequences because they felt like something worth remembering.

Not every creative impulse needs to become a company.

Not every hobby needs to become a channel.

Not every beautiful thing needs to explain how it scales.

Make something with no stakeholder and a high standard.

Let it become useful later.

Or let it remain yours.

What is something you want to make that nobody is waiting for? Reply and tell me. Naming it may be the first useful thing you do with it.

-zc

P.S. If you like essays about taste, ambition, creative work, technology, and the strange effort of remaining a person while becoming professionally useful, subscribe to Don’t Feed The Algorithm.

Subscribe now

Rabbit hole for the overcaffeinated

- Falling in Love with Film & Promising Not to Buy a Leica M3 — a story about difficult machines, family memory, photography, a hazy dinner in New York, practical intentions, and the predictable failure of those intentions.

- How to Do Great Work by Paul Graham — especially useful on curiosity, self-directed projects, and discovering what deserves your effort by doing the work rather than planning your identity around it.

- An Afternoon in Florence

— a small personal film made from wandering Florence before my wedding. No grand premise required.

- Wanting Things Without Irony — the adjacent argument for stating a desire clearly enough that it can acquire cost, evidence, and a visible next act.

Yesterday, the AI coworker acquired a laptop.

Not metaphorically. Grok Bot launched in beta as a group of persistent AI workers that can get their own cloud-computer environment, sign into the software you already use, keep working after your laptop closes, remember prior work, learn routines, and ask for approval when they need it.

You can reportedly assign one Bot to sales research, another to recruiting, another to expenses, and a Chief of Staff Bot to coordinate the others.

Which is either the beginning of a much leaner company or the setup to an excellent workplace sitcom in which nobody can explain why the Expense Bot invited the Talent Scout to renegotiate the internet bill.

The product is interesting. More importantly, the product makes a category shift feel concrete.

We are no longer only buying software that helps a person do work.

We are beginning to assign work to software.

That changes the purchasing decision.

A normal software evaluation asks what the product can do, whether it integrates with your stack, how much it costs, and whether employees will use it.

An AI coworker evaluation has to ask something closer to what we ask before giving a person a job, credentials, context, and the authority to act:

What result will you own, what are you allowed to touch, how will I know the work is right, and what happens when it is not?

Grok Bot is reportedly included in a $200-per-month individual plan and a $120-per-seat team plan. That price will attract attention, but it is not the most important number.

The most important number is the cost of the work you accept.

Grok Bot is not merely another chatbot

I have not tested Grok Bot, so this is not a review of its reliability. SpaceXAI has not published agentic-task benchmarks for it either. The current capability descriptions come from the company’s launch materials and early coverage, not from my own controlled use.

That boundary matters because the product promise is substantially larger than “Grok gives good answers.”

According to VentureBeat’s detailed launch report, Grok Bot is designed around persistent workers with specific roles. Each Bot can operate a computer environment, use websites and applications, save demonstrated workflows as routines, remember corrections and preferences, and coordinate with other Bots.

The system is specifically meant to work across software that may not have a clean API or MCP connection. Instead of waiting for every application to expose an agent-ready interface, the Bot can reportedly use the interface more like a person would: look, click, type, navigate, and continue.

That is the compelling part.

It is also the dangerous part.

An API usually gives software a defined set of actions. A computer-using agent can encounter whatever the interface puts in front of it. Pop-ups. Changed menus. Duplicate buttons. An unexpected login screen. A customer record that looks almost identical to another customer record. A confirmation dialog written by somebody who believes “Are you sure?” is a complete safety architecture.

The agent does not become safe because the interface looks familiar to us.

It becomes harder to predict because the software was designed for a human who carries context the interface never had to encode.

“AI teammate” is a product category and a management trap

I understand why companies use the coworker metaphor.

It gives the agent a legible shape. A chatbot answers. A coworker owns. A tool waits. A coworker notices. A workflow runs. A coworker remembers what happened last Tuesday and knows who should hear about it.

The metaphor helps people imagine delegation.

It can also conceal the hard part.

A capable employee arrives with judgment, social context, an understanding of consequences, and the ability to notice that the instruction is technically possible but obviously wrong. They can ask why. They can recognize when the customer’s name does not match the account. They may know that the CEO saying “send it” in one Slack thread did not authorize emailing 8,000 people from an unapproved list.

An agent gets whatever judgment the system can access, infer, or has been explicitly taught to preserve.

That is not an argument against agents. I use them constantly. I have [built my own company-style workspace where different AI agents have scoped jobs, memories, tools, and stopping rules.

The experience made me more optimistic about agentic work and less impressed by the phrase “AI teammate.”

Names and avatars are cheap. Reliable role design is not.

The agent has to earn the job.

A demo proves motion, not employment

Agent demos are unusually persuasive because we watch the work happen.

The cursor moves. The website opens. The CRM fills. The email draft appears. One Bot hands a task to another Bot. The system looks busy in a way that feels suspiciously employable.

But visible motion can hide four different questions:

1. Did the agent complete the intended steps?

2. Was the result correct?

3. Was the action allowed?

4. Did the completed work improve the business outcome?

Those are not the same test.

A sales Bot can research 100 accounts and fill every CRM field while using stale information. An expense Bot can process every receipt and misclassify the exact category Finance cares about. A recruiting Bot can create a beautiful shortlist from criteria the company should never have used. A customer-support Bot can close tickets quickly by giving confident answers the product does not support.

The agent completed the task.

The company acquired a faster mistake.

This is why I keep coming back to accepted work as the useful unit. Not prompts. Not agent hours. Not tasks attempted. Not colorful activity inside the cloud computer.

Accepted work means the result met a defined quality bar, respected the permission boundary, survived review, and was usable in the real workflow.

If we cannot define that unit, we are not buying labor yet.

We are buying possibility with a timesheet.

The AI Coworker Hiring Test

Before you give a persistent agent a title, applications, memory, and recurring responsibility, make it pass nine tests.

Read more

A company launches a new feature.

Product calls it a smarter way to detect account risk.

Marketing calls it an AI-powered intelligence layer.

Sales calls it an automated retention engine.

Support tells customers it is a dashboard that highlights unusual activity.

All four teams are describing the same thing.

Technically.

The company has not created four lies. It has created four slightly different products wearing one release date.

This happens constantly in SaaS. The source material is usually reasonable… a product brief, a launch meeting, a few screenshots, maybe a Slack thread containing the phrase “we should tighten the narrative” moments before everyone returns to their actual jobs.

Then each team translates the feature for its own immediate need.

Product explains the mechanism. Marketing expands the possibility. Sales sharpens the outcome. Support narrows the promise to whatever it can reliably help a customer do at 4:47 p.m. on a Friday.

By the time the language reaches the market, the customer has heard four versions of what the product is, what it does, and what they should expect from it.

We tend to call this a messaging problem.

It is usually a product-truth problem.

Positioning does not live in the positioning document

A positioning document can be excellent and still have no operational effect.

It can identify the customer, category, problem, alternative, differentiated value, and proof. It can receive twelve approving comments and one late suggestion to replace “helps” with “empowers.” It can be filed in the correct workspace beneath a title containing the word *final*.

None of that means the customer will experience it.

Positioning becomes real when it survives contact with the surfaces where people actually encounter the company:

- the homepage that earns attention;

- the sales deck that frames the problem;

- the demo that explains the mechanism;

- the release note that announces the change;

- the onboarding flow that sets expectations;

- the help article that explains the conditions;

- the support reply that handles the exception;

- the renewal conversation that has to prove the value occurred.

Those surfaces have different jobs. They should not use identical copy.

A support agent should not answer a troubleshooting question with the homepage hero. A salesperson should not deliver a database schema when the buyer is trying to understand the business case. A product manager should not turn a release note into a small inspirational speech about the future of work.

Consistency is not repetition.

Consistency means the meaning survives the translation.

That sounds obvious until you inspect a company end to end. Then you discover the homepage promises the outcome, the demo shows a workflow, the help center explains a narrower capability, and Support has quietly developed the most accurate positioning in the building because customers keep asking where the magic went.

A fictional teardown that is not very fictional

Imagine a B2B SaaS company, let’s call it Northstar, launching a feature called Signal Desk.

Signal Desk monitors customer-account activity and surfaces patterns that may deserve attention. It groups relevant events, explains why a pattern was flagged, and lets a customer-success manager review the evidence before deciding what to do.

That is the working product truth.

Now watch what happens as it moves through the company.

Product

Signal Desk uses machine learning to analyze behavioral events and identify statistically unusual changes across account activity.

This is mechanism-heavy, but mostly accurate. It explains how the feature produces a signal. It does not tell the buyer what problem becomes easier to solve.

Marketing

Predict churn before it happens with AI-powered customer intelligence.

Much more exciting.

Also much less bounded. “Predict churn” converts a useful signal into a forecast. “Before it happens” implies timing and reliability the product may not have established. “Customer intelligence” could mean almost anything sold from a booth with decent lighting.

Sales

It tells your team which accounts are going to churn and automatically prioritizes the book of business.

The rep is trying to make the value concrete. Fair instinct. But “deserves attention” has become “going to churn,” and a human review workflow has become automatic prioritization.

The product has crossed from evidence into judgment without anyone explicitly deciding that it should.

Support

Signal Desk flags changes in product activity. A flag does not necessarily mean an account is at risk, and some accounts may not have enough activity for a signal to appear.

This is accurate, useful, and significantly less cinematic.

It is also the first explanation that tells the customer what the system does, what it does not establish, and why the experience may vary.

Put the four versions beside one another:

| Surface | What the customer hears | Hidden shift |

| Product brief | Detects unusual behavioral changes | Mechanism without customer job |

| Homepage | Predicts churn before it happens | Signal becomes forecast |

| Sales call | Identifies accounts that will churn and prioritizes them | Evidence becomes automated judgment |

| Support reply | Flags activity changes that may deserve review | Accurate, but arrives after expectation breaks |

The problem is not that Marketing used better language.

The problem is that every improvement in persuasiveness also changed the product claim.

Most message drift is incentive drift

Every team is rewarded for solving a different problem.

Product wants precision. Marketing wants attention. Sales wants urgency. Customer Success wants adoption. Support wants resolution. Legal wants the sentence to stop creating new kinds of weather.

None of those incentives are wrong.

But without a shared language contract, each function optimizes its surface locally. The words improve for the immediate moment while the product changes underneath them.

Marketing removes the caveat because the caveat weakens the headline.

Sales removes the condition because the condition slows the call.

Product adds technical detail because technical detail feels safer than choosing a customer outcome.

Support restores the caveat because reality has now opened a ticket.

This is why a messaging review cannot be limited to the launch asset. The launch asset is one frame in a longer customer experience.

If the homepage creates an expectation the product cannot explain, the positioning is not strong. It is merely early.

The support queue is a positioning research system

Support language is often treated as downstream cleanup: the copy used after Marketing and Sales have done the strategic work.

That is backwards.

Support sees where the market’s interpretation collides with the product’s behavior.

Customers ask:

- Does this tell me an account will churn, or only that activity changed?

- Why do some accounts have signals and others do not?

- Does the system take action automatically?

- What data does it use?

- Can I see why something was flagged?

- What should my team do next?

Those are not merely support questions. They are evidence that the company has failed to preserve an important distinction somewhere earlier.

The best support replies often contain positioning gold because they have been pressure-tested against confusion. They name the mechanism in plain language. They expose the boundary. They explain the condition. They give the user the next action.

Then the insight dies inside the ticket.

A strong positioning system routes repeated questions back into the homepage, demo, onboarding, release note, and product itself. It does not celebrate lower ticket volume because Support got better at manually explaining a promise nobody upstream corrected.

Customer language should revise company language.

Otherwise “voice of customer” is just a meeting where everyone respectfully listens to the recording and then reopens the old deck.

Clear positioning preserves six things

For any consequential product or feature, every team should be able to answer the same six questions.

The wording can change. The answers cannot quietly mutate.

1. Who is this for?

Not the entire total addressable market. The person with the problem and enough authority, context, or workflow ownership to use the product.

For Signal Desk: customer-success leaders and managers responsible for finding which accounts may require human attention.

2. What problem does it help them handle?

Name the moment before the feature.

For Signal Desk: account teams cannot manually inspect every change across every customer, so important shifts are easy to miss or discover late.

3. What does the product actually do?

This is the mechanism in buyer-readable language.

For Signal Desk: it groups relevant account activity, flags unusual changes, and shows why the pattern may deserve review.

4. What becomes possible?

This is the outcome, stated at the level the mechanism can support.

For Signal Desk: teams can focus review on accounts with meaningful changes instead of manually scanning the entire book of business.

Notice what it does not say… prevent churn automatically.

That may be the larger business ambition. It is not the direct product output.

5. What proves the claim?

A screenshot is evidence that an interface exists. It is not proof that the outcome occurs.

Proof might include an accepted signal, a reviewed account, reduced manual review time, earlier intervention, improved coverage, or a controlled comparison against the prior workflow. The right proof depends on the claim.

6. What remains human, conditional, or uncertain?

What must the user review? What data has to exist? What can the system not infer? What varies by account? What is not automated?

This is not disclaimer copy stapled to the bottom of the page.

It is part of the product definition.

The Product Language Contract

Before the next launch, create one table. Keep it short enough that people might actually use it.

| Contract field | Canonical answer | Allowed translation | Prohibited drift | Proof / source | Owner |

| Customer | Who this is for | Role-specific phrasing | Expanding to “every team” without evidence | Research / segmentation | PMM |

| Problem | The customer moment | Different examples by segment | Inventing a larger pain to raise urgency | Interviews / tickets | PMM + Product |

| Mechanism | What the product does | Technical or plain-language depth | Turning analysis into prediction or action | Product spec / demo | Product |

| Outcome | What becomes easier or better | Role-specific business relevance | Promising a downstream result the mechanism cannot establish | Baseline / pilot | PMM + Analytics |

| Proof | Evidence supporting the claim | Case study, metric, demo, artifact | Treating existence or activity as outcome proof | Evidence source | Named evidence owner |

| Boundary | Human gate, condition, limitation | Surface-appropriate explanation | Removing the boundary where it changes expectation | Product / Legal / Support | Product + Support |

Then write the surface adaptations beneath it.

Homepage

Lead with the customer problem and supported outcome.

Find the account changes worth reviewing—without manually scanning every customer.

Demo

Show the mechanism and human decision.

Signal Desk groups the activity behind each flag, explains what changed, and lets your team decide whether the account needs action.

Sales

Connect the outcome to the buyer’s current workflow without upgrading the claim.

Instead of asking each CSM to inspect every account, your team can begin with the changes most likely to deserve attention and review the evidence before acting.

Onboarding

Set the conditions for value.

Connect the required activity sources and confirm account coverage. Signals appear when the system has enough relevant history to identify a meaningful change.

Support

Resolve the exception without introducing a new product definition.

A signal reflects an unusual activity change, not a churn prediction. If no signal appears, the account may be stable or may not yet have enough connected activity to evaluate.

Same product.

Different depth, context, and job.

No surprise sequel where the support team reveals what the product really meant.

Run the “same product” test

Pull five live artifacts:

1. homepage or product page;

2. current sales deck or call transcript;

3. latest release note or announcement;

4. onboarding or empty state;

5. three recent support replies about the feature.

For each one, highlight the language that answers:

- customer;

- problem;

- mechanism;

- outcome;

- proof;

- boundary.

Then compare them.

You are looking for four failure modes.

Missing

One surface never explains an essential part of the product.

The homepage has an outcome but no mechanism. The demo has a mechanism but no proof. The onboarding never explains the condition required for value.

Inflated

A supported claim grows as it moves closer to revenue.

“Flags unusual activity” becomes “predicts churn.” “Prepares a recommendation” becomes “automates the decision.” “Can reduce manual review” becomes “eliminates manual work.”

Contradicted

Two surfaces make incompatible claims.

Sales says the system takes action automatically. Support says the user must approve every action. The pricing page says the capability is included. The help center says it requires an upgrade.

Orphaned

A useful truth exists in one function but never travels.

Support knows the top source of confusion. Sales knows the objection blocking deals. Product knows the data limitation. Customer Success knows which setup step predicts adoption. None of it changes the shared language.

For every mismatch, choose one of three actions:

- Correct the surface when the language drifted from the product.

- Correct the product when the repeated explanation reveals a broken experience.

- Correct the contract when the company never made the underlying decision.

Do not solve every disagreement by making the copy vaguer.

Sometimes the teams disagree because the positioning is unclear. Sometimes they disagree because the product strategy is unclear. A softer adjective will not save you from choosing.

Your company should sound like one mind, not one mouth

I do not want every employee reciting the same approved paragraph like the company installed a tiny press secretary behind their teeth.

Good teams adapt language. They use examples their audience understands. They change the level of detail. They answer the actual question in front of them.

But adaptation should reveal the same product from a useful angle, not manufacture a more convenient product for each conversation.

The customer should be able to move from homepage to demo to onboarding to support without discovering that the verbs changed their meaning along the way.

That is the real standard.

Not message consistency as corporate tidiness.

Meaning continuity as product trust.

Your positioning is not clear because the positioning document is clear. It is clear when Product can explain the mechanism, Marketing can earn attention without enlarging the claim, Sales can connect value without inventing certainty, and Support can handle reality without correcting the entire company in private.

One product can support many conversations.

It should not require many truths.

Where does your company’s product change meaning: homepage, demo, onboarding, or support? Reply with the sentence that drifts. I may turn a few anonymized examples into a future teardown.

-zc

P.S. If you like practical essays about positioning, product, AI, and the strange things that happen between strategy and the customer, subscribe to Don’t Feed The Algorithm.

Subscribe now

Rabbit hole for the overcaffeinated

- April Dunford — Obviously Awesome: the clearest practical foundation I know for positioning around competitive alternatives, differentiated value, customers, and market context.

- The Mom Test by Rob Fitzpatrick: useful for getting closer to customer reality without collecting polite validation disguised as research.

- Intercom on using customer-support insights across the company: a useful extension of the idea that repeated tickets are not only service work; they are product, positioning, and education evidence.

- If I Had to Build a Startup Content Engine From 0 in 30 Days, Here’s Exactly What I’d Do — a practical system for moving from topics and output into belief, proof, customer language, and learning.

- Your Brand Voice Doc Is Corporate Astrology — the adjacent argument: adjectives do not create consistent language; examples, refusals, and real decisions do.

I have a verbal tic.

Whenever I say something I care about, I immediately put a joke after it.

I can watch it happen in the draft. I type the plain sentence, leave it alone for about two seconds, then rush back in with a punchline like the sentence has been left unattended near traffic.

I want to build a company of my own someday. Horrifying sentence. Please do not clip that for a podcast.

I want to become an excellent writer. Gross. Somebody hide the tote bags.

I want to make work people remember. Okay, relax, Hemingway.

The joke is almost automatic. It arrives before the sincere sentence has even finished parking.

I have always thought of this as self-awareness. Nobody wants to be the guy speaking about his destiny with both hands wrapped around a ceremonial mug. I certainly do not. There should be legitimate consequences for saying “my legacy” before breakfast.

But lately I have started wondering whether the joke is doing more than keeping me moderately likable.

Maybe it is keeping me safe.

Irony gives desire an emergency exit

A few weeks ago, in a birthday essay about becoming less full of shit, I wrote that I wanted to get better at wanting what I want without immediately dressing it up in irony so nobody could accuse me of caring too much.

I thought that was one line in the essay.

It turns out it may have been the whole problem.

Irony is useful. It signals that you understand how you sound. It keeps intensity from curdling into self-importance. It can turn a confession into something another person can actually sit beside without slowly looking for the door.

I like funny people. I like self-aware people. I do not want to replace humor with the spiritual energy of a keynote speaker walking toward the edge of the stage.

But irony also creates an emergency exit.

If the dream fails, I was kidding.

If the idea sounds too ambitious, I know. That was the joke.

If somebody thinks I am trying too hard, I can act like I agree with them.

The sincere sentence gets to enter the room, but it has to wear a disguise.

This is socially convenient. It is also a strange way to live.

At some point, the performance of detachment starts requiring more energy than simply caring.

Detachment is easy to perform in public

The internet is very good at making commitment look naïve.

Not because people do not want things. We clearly want things. Better work. More money. A stronger body. A family. A book. A company. A home. A creative life. A reputation for doing something unusually well.

We just learn to describe those wants sideways.

You are not trying to become a writer. You are “messing around with a newsletter.”

You are not building a product you hope becomes a real company. You are “shipping a little side project.”

You do not care deeply about the work. You are “having fun with it.”

Sometimes that language is accurate. Early things should be allowed to be small. Experiments need room to fail without becoming identity crises.

But sometimes “just playing around” is a legal disclaimer attached to your own ambition.

It means: I want this, but I would also like immunity from being judged by how badly I want it.

That immunity is f*cking expensive, man.

You cannot build a life around a desire you keep introducing as a bit.

Eventually, wanting something asks you to become specific. Specific desire creates the possibility of specific failure. “I want to make things” is atmospheric. “I want to write an essay every week that earns a place in someone’s inbox” can go wrong in public.

“I might build something someday” preserves potential. “I want to build a company and I am practicing the skills now” creates a standard your behavior can contradict.

That is why the joke feels so good. It blurs the scoreboard.

The problem is not the joke

To be clear, I am not giving up jokes.

This newsletter would lose at least 40% of its load-bearing architecture, and I would have to develop an actual personality.

The problem is not using humor around serious things. Humor is often how I get close enough to say them. It punctures the performance before the performance becomes unbearable. It lets me acknowledge that ambition can be sincere and ridiculous at the same time.

The problem is whether the joke serves the truth or erases it.

A good joke lets the sincere sentence breathe.

A defensive joke pulls it back before anyone can respond.

I have noticed this distinction in my older writing. The pieces that feel most like me usually disarm the self-importance, then return to the thing that matters. The camera purchase can be impractical and still represent craft, memory, control, and a way of seeing. A birthday audit can be absurd and still ask whether my behavior matches my ambition. Wanting to be a founder can make me cringe and still be true.

Self-awareness should make sincerity believable.

It should not make sincerity deniable.

I want a lot

This is the part where I am supposed to prove the thesis by saying what I want plainly.

Annoying.

I want to build a company of my own.

I want to become a writer whose work is useful, recognizable, and worth returning to.

I want to make products that feel considered all the way through… the idea, the interface, the language, the business, the experience after someone pays.

I want to become genuinely excellent at the strange overlap of product, brand, growth, technology, and taste.

I want a strong body, a calm home, a life full of people I love, and enough attention left to notice where I am.

I want ownership. Freedom. Mastery. Time. Work with consequence.

I want the life and the work to feel like they belong to the same person.

There. No joke.

The uncomfortable part is not that these desires are unusual. They are not. The uncomfortable part is claiming them without first making myself smaller for the comfort of an imaginary audience.

That does not mean I deserve any of them.

Wanting is not evidence. Desire can become its own form of cosplay if it never acquires a calendar, a cost, or a body of work.

Sincerity is not saying the big sentence louder.

Sincerity is accepting what the sentence asks of you next.

Every real want has a cost attached

“I want to write” sounds lovely until it means writing when the idea is not cooperating.

“I want to build a company” sounds romantic until it means choosing a problem, listening when customers ruin your elegant theory, learning the parts of the work you cannot aesthetic your way around, and being responsible when the consequences stop being hypothetical.

“I want to be healthy” sounds obvious until it has to compete with a Saturday brunch in The Village. Hey, I love a good mimosa… or 12.

“I want a rich life” sounds beautiful until it requires protecting attention from work that will happily eat all of it.

A real want changes what you are willing to pay for in time, discomfort, repetition, embarrassment, and refusal.

That is the line between ambition and fantasy.

Fantasy keeps the image and negotiates away the cost.

Ambition accepts the cost, then starts collecting evidence.

This is also why plain desire feels exposing. Once you say what you want, people can compare the sentence with your life. More importantly, you can.

The gap becomes visible.

I used to think that visibility was the danger.

Now I think it may be the point.

The Unironic Sentence

Here is the small exercise I am trying. It is less a framework than a way to catch myself reaching for the emergency exit.

Take one thing you keep describing with a hedge, joke, or layer of strategic ambiguity. Then finish these five lines.

1. I want…

Write the sentence with no “maybe,” “kind of,” “someday,” or “I know this sounds stupid.”

Do not make it impressive. Make it accurate.

I want to write a book.

I want to change careers.

I want to build a company.

I want to make art again.

I want to be a more present parent.

2. It matters because…

Do not turn the answer into a pitch.

Not everything you want needs to improve an industry, create a movement, or make you an optimized node in the knowledge economy. Some things matter because they make you feel more alive, more honest, or more like yourself.

Name the private reason before the socially acceptable one eats it.

3. The cost is…

What will this require that the fantasy keeps editing out?

Time. Repetition. Money. Boredom. Beginnerhood. Public failure. A difficult conversation. Saying no to something that looks respectable. Letting another person see work that is not ready.

If you want the image but reject every cost, that is useful information.

4. The evidence would be…

What would exist if the want became real?

A draft. An application. A prototype. A paid invoice. A recurring dinner. A stronger body. A finished film. A conversation you have been avoiding. A Tuesday that looks different.

Evidence turns the sentence from identity into practice.

5. The next visible act is…

Choose something small enough to do and real enough to make retreat slightly less comfortable.

Not “research.” Not “think about my options.” Not “build the strategy.”

Send the email. Book the class. Publish the page. Make the call. Put the session on the calendar. Tell the person. Finish the first ugly version.

The goal is not to announce your dream to the internet.

The goal is to remove your own plausible deniability.

Earnestness is not a personal brand

There is a version of this idea that becomes its own performance.

You can become the person who is publicly, aggressively sincere about everything. Every morning is sacred. Every workout is a vote for destiny. Every product update is a chapter in the founder journey. Every bowl of oatmeal is somehow about courage.

No thank you.

Earnestness does not require constant disclosure. Some desires get stronger when they are protected from distribution. Some work needs privacy before it needs accountability. Some ambitions are shared with five people, not five thousand.

The point is not to perform caring.

It is to stop performing not caring.

Those are different jobs.

One turns desire into content. The other lets desire become instruction.

I still want the irony. I want the snapback after a sentence gets too polished. I want the joke that proves I know ambition can make people weird. I want enough self-awareness to recognize when I am falling in love with the story of myself.

But I do not want the joke to hold veto power anymore.

I do not want to spend my life saying “it would be cool if” about things I am quietly building my life around.

I want to build a company of my own.

I want to make work worth remembering.

I do not know exactly what either sentence will cost yet.

I am going to keep finding out.

A question for you

What is the sentence you keep making safer with irony?

Finish this without hedging… I want…

Reply and tell me. One sentence. No business case required.

-zc

P.S. If you like essays about ambition, taste, building things, and staying recognizably human while doing it, subscribe to Don’t Feed The Algorithm. I promise to remain at least a little embarrassed by all of this.

Subscribe now

Rabbit hole for the overcaffeinated

A few things that helped me think about sincerity, commitment, attention, and making the private desire real:

- David Foster Wallace — “This Is Water”: a useful reminder that attention and meaning are practices, not personality traits we get to claim once and keep forever.

- Brené Brown — “The Power of Vulnerability”: popular for a reason; useful on what we protect when we avoid exposure.

- Paul Graham — “How to Do Great Work”: practical thinking about curiosity, ambition, commitment, and the long process behind work that matters.

- Oliver Burkeman — Four Thousand Weeks: a useful counterweight to abstract ambition because every serious want is also a decision about finite attention.

- Austin Kleon — *Show Your Work!: a short argument for letting practice become visible without turning yourself into a motivational content product.

Internal rabbit holes:

- Another Year Older, Still Trying to Become Less Full of Shit — the line that started this essay.

- Trying to Become a Top 0.1% Human — on taking a ridiculous ambition seriously enough to make it useful.

- Your Ambition Needs a Place to Live — on building a container for the thing you keep saying matters.

I have built my own company Slack where nearly everyone else is an AI agent.

I run work through Hermes, keep structured memory in Obsidian, use Claude Code to build products, and have opinions about context windows that would make a normal person quietly change seats.

This makes me absurdly useful in certain situations.

It also makes me an absolutely terrible model for enterprise AI adoption.

Most employees do not want to maintain skill files, route tasks between models, or develop a sophisticated philosophy about when to clear context. They want the invoice processed. They want the campaign brief finished. They want the customer question answered without spending twenty minutes copying information between systems that have apparently never been introduced.

The biggest mistake companies make with AI is turning the behavior of their most obsessive power users into the rollout plan for everyone else.

Give everyone a license. Schedule prompt training. Recruit a few evangelists. Put monthly active users on a dashboard. Wait for productivity to happen.

Then six months later, a small group is running agent fleets before breakfast, another group is using the tool to rewrite emails, and most people have forgotten which tab it lives in.

The dashboard says adoption.

The work feels suspiciously familiar.

Power users prove possibility, not normality

I started thinking about this after reading Vasuman Kilaru’s X article, ”AI Adoption is a Myth”

He describes a pattern from Varick’s enterprise work… a small slice becomes deeply AI-native, a larger slice uses the tools weakly, and many employees barely use them at all.

His exact distribution comes from Varick’s own observations, not a universal benchmark. But the shape feels right because the incentives are obvious.

The people pushing hardest for AI inside a company are usually the least representative people in it.

They are curious about the technology itself. They will tolerate broken interfaces because the underlying capability interests them. They spend nights and weekends learning what the model does well, where it fails, how much context to provide, which workflows deserve deterministic software, and how to review an answer that sounds finished but is not.

They enjoy the craft.

Most of the company did not apply for that craft.

This does not make everyone else lazy, resistant, or doomed to wander through the future carrying a paper calendar. It means they were hired for finance, sales, recruiting, customer support, operations, design, or marketing. AI may change how those jobs work. It does not follow that everyone performing them needs to become a tiny AI consultant.

Power users are still enormously valuable. They explore the frontier, discover useful patterns, and show the company what is possible before the org chart knows how to describe it.

But they are scouts.

You should not make the whole company live like the expedition.

We keep measuring the easiest layer

“Adoption” sounds like a business outcome. Most of the time, it is an activity count wearing a nicer jacket.

Did the person receive a license?

Did they log in this month?

Did they send five prompts?

Did one team report using AI in at least one business function?

Those questions describe exposure and activity. They tell you almost nothing about whether work changed.

McKinsey’s 2025 State of AI report captured the contradiction neatly… reported organizational use had become widespread, while most respondents still reported no material earnings impact from generative AI. That does not mean the tools are useless. It means “someone used AI somewhere” is a very generous definition of transformation.

A useful measurement ladder looks more like this:

1. Access

Could the person use the tool?

This is a permission question. Licenses, connectors, security approval, and account availability live here.

2. Activity

Did the person invoke it?

Logins, prompts, sessions, token volume, and weekly active users live here.

3. Capability

Can the person use it reliably for a defined job?

This requires a task, a quality bar, and some way to tell whether the output is correct. “Uses Claude” is not a capability. “Can turn a transcript into an approved customer brief with every factual claim linked to the source” is.

4. Workflow displacement

Did part of the work move from manual effort into reliable assistance or automation?

Now we can ask what share of a workflow is still performed manually, what the system prepares, which actions it completes, and where a person must re-enter.

5. Business impact

Did cost, speed, quality, risk, employee capacity, or revenue change?

This layer needs a denominator, a cohort, a baseline, and enough honesty not to attribute every pleasant quarter to the chatbot rollout.

Most AI dashboards stop at level two because levels one and two are easy to instrument.

The company can prove that 4,000 people had access and 2,100 opened the product. It is much harder to prove that the monthly close became two days faster without increasing correction risk, or that sales reps created better account plans rather than simply creating more of them.

Harder does not mean optional.

If the metric cannot distinguish “opened the tool” from “changed the work,” it should not be presented to the board as evidence of transformation.

Using AI well is a real skill

There is a slightly uncomfortable tendency to talk about AI as if the interface made the skill disappear.

There is a text box. Everyone can type. Therefore everyone can use it.

Sure.

There is also a shutter button on a camera. This has not made everyone Annie Leibovitz.

Using AI well requires judgment before, during, and after the model produces something. You need to know what context matters, what information the model may receive, what the output should look like, how to test it, when to use normal software instead, and which consequences still require a person with a name.

I learned this while using Claude Code to build products. It is trivial to point a model at a repository, paste a ticket, and watch many colorful things happen. It is much harder to define the files it may touch, specify the behavior, create the right test, inspect the diff, catch the unrelated change, run the actual user path, and decide whether the feature is safe to ship.

That is why I wrote about using Claude Code without pretending faster implementation made me an engineer. The model expanded what I could direct. It did not inherit responsibility for what the product could break.

The same is true in every function.

A marketer can generate a campaign in seconds. Someone still has to know whether the claim is true, whether the audience cares, and whether the result sounds like every other company currently yelling “AI-powered” into the void.

A finance team can classify invoices faster. Someone still has to define the exception policy, approval threshold, audit trail, and response when the vendor, amount, or account does not match.

A recruiter can summarize candidates. Someone still has to decide what evidence belongs in that judgment and what sensitive information should never enter it.

The text box did not eliminate the work.

It moved the work into specification, verification, exception handling, and accountability.

The useful lesson from a customer-support study

One of the strongest studies on AI at work did not ask thousands of employees to become prompt engineers.

Researchers Erik Brynjolfsson, Danielle Li, and Lindsey Raymond studied the introduction of a generative AI assistant across 5,179 customer-support agents. The tool increased issues resolved per hour by 14% on average. Novice and lower-skilled workers improved by 34%, while experienced workers saw minimal impact.

The interesting part is not only the average productivity gain. It is how the capability reached the worker.

The assistant sat inside a defined workflow. It helped agents respond to real customer problems and appeared to spread patterns from stronger workers to newer ones. The job, context, and performance measure already existed. The employee did not have to invent a use case, construct an agent, or become fascinated by model behavior.

That is a much better model for making AI useful across a company.

The company embedded assistance where the work already happened. The worker remained responsible for the customer interaction. The system made useful expertise easier to access.

This is very different from dropping a general-purpose chatbot into the organization and asking every employee to discover their own path to value between meetings.

One approach redesigns the work.

The other distributes homework.

A company needs two AI strategies

Trying to force every employee into the same AI behavior creates a bad compromise. The power users feel constrained by a generic tool, while everyone else gets an intimidating blank box and a training deck they will never open again.

A better company has two connected strategies.

The frontier path

Give the power users room to experiment.

They need broad tools, safe sandboxes, access to models, technical partners, reusable context, clear data boundaries, and somewhere to publish what works. Reward them for turning private advantage into organizational capability.

This last part matters. A clever workflow trapped on one person’s laptop is personal productivity. A reviewed, installable, maintained workflow with an owner and a measured job can become company infrastructure.

Status may work better than moral appeals here. Let people earn recognition for the workflows other teams adopt, the hours removed, the errors caught, or the systems made easier to operate. Make sharing part of the reward rather than an act of charity performed after the power user finishes their actual job.

I have written about building an agent workspace with explicit channels, memories, permissions, and stopping rules. That level of machinery can be useful for the people designing systems.

It should not become the minimum interface required to submit an expense report.

The embedded path

For everyone else, put AI inside the workflow they already understand.

The new interaction should often be mechanically simple:

- approve;

- reject;

- edit;

- escalate;

- inspect the evidence.

An accounts-payable analyst does not need to prompt an agent to inspect every invoice. The system can extract the fields, match the vendor, check the purchase order, flag the exception, and preserve an audit trail. The analyst handles the judgment the system cannot safely make.

A sales rep should not have to explain the entire company to a blank chat every Monday. The system can prepare the account brief from approved sources, show what changed, link the evidence, and ask the rep to correct or approve it.

A marketer should not need seven clever prompts to turn a customer call into usable intelligence. The workflow can ingest the approved transcript, extract claims and objections, attach timestamps, and route the result to the right person for review.

The employee still matters. In many cases, their judgment matters more because less of their time is being consumed by clerical motion.

But the interface no longer asks every person to become good at the machinery behind it.

The best AI workflow may be the one nobody prompts

Prompting became the symbol of AI work because chat was the first interface most people understood.

It is a powerful interface. It is also a strange default for repeatable organizational work.

Imagine asking employees to query the payroll database by writing natural-language requests every two weeks. Or telling a warehouse team that inventory management now begins with an open text box and a company-wide prompt contest.

We would call that unfinished software.

Yet companies routinely treat a blank chat as the completed interface for AI transformation.

A prompt is useful when the job is exploratory, ambiguous, creative, or genuinely benefits from conversation. It is less useful when the same trigger, context, rules, and output repeat every day.

Once a workflow is understood, the prompt should often disappear into the system. The employee should encounter the prepared work, the exception, the evidence, or the decision.

That does not mean hiding AI so completely that nobody can inspect what happened. Background automation without visibility is how small mistakes receive enterprise distribution.

The system should make the consequential parts legible:

- what triggered the work;

- which sources it used;

- what the model changed or produced;

- how confident or uncertain the result is;

- what rule caused an escalation;

- who approved the action;

- how to correct it;

- what gets preserved for audit and learning.

The machine can move into the background.

The accountability cannot.

The Workflow Displacement Ledger

Stop beginning the review with “How many employees used AI?”

Choose one recurring workflow and measure the work itself.

The unit should be something the business actually recognizes: invoices processed, support cases resolved, briefs approved, accounts researched, claims reviewed, candidates screened, contracts routed, campaigns launched, or reports completed.

For each workflow, create this ledger:

| Field | What to record |

| Workflow | The specific recurring job, with a start and a completed outcome |

| Denominator | Total units of work during the measurement period |

| Cohort | Team, role, market, customer type, or other population included |

| Baseline | Manual cycle time, cost, error/rework rate, and quality before the change |

| Manual share | Units completed entirely through the prior human process |

| Assisted share | Units where AI prepared work and a human completed it |

| Automated share | Units completed without manual initiation |

| Human gate | The exact decision a person must approve, reject, edit, or escalate |

| Exception rate | Share requiring intervention outside the normal path |

| Rework rate | Share corrected after AI produced or completed the work |

| Cycle time | Time from valid trigger to accepted outcome |

| Unit cost | Human time plus software/model cost per accepted outcome |

| Quality | The job-specific acceptance or accuracy measure |

| Outcome | The business result the workflow is supposed to influence |

| Attribution caveat | Other changes that may have affected the result |

| Review trigger | The date, threshold, failure, or policy change that reopens the design |

The categories should be boringly precise.

“Hybrid” is not enough. Did AI draft the work? Recommend the decision? Execute the action? Did a human inspect every unit or only exceptions? What exactly counts as complete? If the output was rejected and redone manually, does the dashboard still count it as an AI success?

Then compare a cohort or time period against a real baseline.

Do not celebrate that 60% of invoices “touched AI” if the exception rate doubled, the analysts spent more time correcting vendor fields, and the monthly close did not move. Do not declare victory because people generated twice as many campaign briefs if the approval rate fell and no additional campaigns shipped.

Activity is evidence that something happened.

It is not evidence that something improved.

What I would report to the board

I would keep access and activity metrics. They are useful operational signals. I would stop letting them carry a story they cannot support.

Instead of:

72% of employees used our AI tools this month.

A hypothetical report might read:

In the North American support cohort, AI assisted 61% of 18,400 eligible cases. Accepted resolution time fell from 11.2 to 8.9 minutes. Reopen rate remained within 0.3 percentage points of baseline. New agents saw the largest improvement. Escalations involving billing disputes still require human review. We have not yet established an effect on retention.

That statement is less cinematic.

It is also useful.

It gives the denominator, cohort, eligible event, baseline, quality constraint, human boundary, and causality limit. A leader can inspect it, challenge it, and decide whether the workflow deserves more investment.

The purpose of measurement is not to make the rollout look inevitable.

It is to tell the company where the system works, where it fails, and what should happen next.

AI expertise can be concentrated. Its benefits should not be.

I do not think prompting will disappear. I do not think training is useless. Companies should expose people to the tools, identify natural power users, teach basic judgment, and give interested employees a safe way to go deeper.

But “everyone becomes AI-native” is not a serious operating plan.

Some people will become extraordinary at directing models. Some will use a few useful features. Some will never care about the machinery and will still be excellent at their jobs.

The company does not need to flatten those differences.

It needs to design around them.

Let the power users explore, build, test, and publish. Let domain experts define the work, exceptions, and quality bar. Let product, engineering, security, operations, and legal turn the successful patterns into systems people can trust. Let employees interact with those systems through the smallest interface the job requires.

Then measure whether the work changed.

The point of enterprise AI is not to create five thousand miniature AI consultants.

It is to let the people who understand the technology redesign the work, then ask everyone else for judgment where their judgment matters.

Stop asking how many employees adopted AI.

Ask how much work changed, who benefited, what it cost, what broke, and whether the result was any better.

What is one workflow at your company where “AI adoption” looks healthy but the work itself has barely changed? Reply and tell me. I am especially curious about the denominator nobody is measuring.

-zc

P.S. If you want more essays about AI systems, human judgment, and the mildly chaotic work of making new technology useful after the demo ends, subscribe to Don’t Feed The Algorithm.

Subscribe now

Rabbit hole for the overcaffeinated

- ”AI Adoption is a Myth” by Vasuman Kilaru](

— the enterprise field observation that sparked this essay, especially the split between power users and everyone else. Treat the percentages as Varick’s reported pattern, not a universal law.

- ”Generative AI at Work” by Erik Brynjolfsson, Danielle Li, and Lindsey Raymond) — a field study of 5,179 customer-support agents showing why embedded assistance, defined tasks, and worker-level differences matter more than generic adoption claims.

- McKinsey’s *The State of AI: How Organizations Are Rewiring to Capture Value) — useful for the gap between widespread reported use and material business impact, plus the organizational practices associated with value.

- Your AI Strategy Is a Management Problem) — my earlier argument that the hard part is deciding what AI owns, what humans own, and how the system learns.

- I Built My Own Company Slack. Everyone Else in It Is an AI Agent.) — the power-user extreme: channels, memory, permissions, stopping rules, and why none of that should become the required interface for the average employee.

When we moved back to New York, I did what any normal person would do.

I built an operating system for the apartment, obviously.

There were floor plans, measurements, retailer tabs, budget tiers, lighting rules, material rules, and enough competing ideas about blue to make me question whether cobalt was a color or a hostage negotiation.

The apartment is a rental on the Upper West Side, so every decision had constraints. The walls stay warm white. The chandelier has to be reversible. The big pieces stay neutral. Personality comes from brass, marble, velvet, art, and a few stronger objects. The bathroom floor, which had committed several aesthetic crimes before we arrived, might be rescued by removable black-and-white checkerboard tile.

This all makes sense to me.

Give me a messy room and I will make a board. Give me a repeated decision and I will make a rule. Give me a life transition and, apparently, I will make a local dashboard with multiple purchasing tiers.

Very spontaneous.

Very alive.

The system worked. We made decisions. The apartment started becoming ours.

Then New York did what New York does.

It kept interrupting the plan.

I am extremely good at making life manageable

This is not false modesty. I can make almost anything easier to operate.

I have systems for work, writing, research, meetings, ideas, health, projects, and the small army of AI agents now doing clerical labor around my life like a very competent digital municipality.

I like a good system because it lowers the cost of starting. It keeps decisions from evaporating. It means I do not have to rebuild my entire brain every Monday morning before I am allowed to have a useful thought.

This is good.

It is also possible to get too good at it.

A perfectly manageable week can still feel strangely uninhabited.

You complete the workout. Answer the messages. Ship the document. Eat the groceries you bought for the person you planned to be. Move each project one respectable square to the right. Finish the day with the clean satisfaction of a machine that has processed its queue.

Nothing went wrong.

Nothing really happened, either.

That is the part I am noticing most since moving back to New York.

The life I can design is useful. The life that interrupts the design is often the part I most remember.

New York keeps putting life between the tasks

New York is not a calm place to discover that you may be over-optimizing.

It is loud, expensive, inconvenient, crowded, and fully willing to turn one simple errand into a minor test of character. The city does not give a f*ck about the elegant little sequence you built in your calendar. It has its own sequence, and for some reason its sequence frequently involves stairs.

But it also puts an absurd amount of life in the space between things.

The walk to dinner is not just transportation. It is windows, dogs, arguments, scaffolding, music leaking out of a car, three excellent coats, one genuinely confusing shoe decision, and a restaurant you did not even know existed yesterday.

The subway is not merely the least glamorous section of a productivity routine. It is hundreds of private worlds briefly sharing a metal room. Someone is reading. Someone is rehearsing. Someone is dressed for a job you cannot identify. Someone is having a day that has nothing to do with your inbox. There’s something magical in that.

A bookstore changes the next thing you think about. A museum changes the pace of your eyes. An overheard sentence gives you a better line than the one you spent 40 minutes trying to manufacture at your desk.

None of this is efficient.

That may just be why it works.

I moved back because I missed the density… the walking, the culture, the strange specificity, the feeling of being around people who are attempting something. Not always sanely. Not always successfully. But visibly.

The city keeps presenting evidence that there are more ways to live than the ones currently represented in my calendar.

That is useful when you are ambitious, because ambition can quietly become a closed system. You choose the goal, build the routine, measure the routine, improve the routine, and then spend so much time managing the machinery of becoming that you stop encountering anything capable of changing what you want.

New York makes that harder.

It makes you porous.

The danger of a life with no accidental inputs

Most of my work is digital. So are most of my inputs.

The feed knows what I have clicked. The newsletter knows what I read. The algorithm knows I am interested in AI, startups, cameras, menswear, apartments, health, marketing, and people who own too many opinions about mechanical objects.

It can keep giving me more of myself forever.

This is convenient. It is also a terrible way to become more interesting.

A feed can deepen an existing interest. It is not very good at giving you a life you did not already signal that you wanted.

That requires contact with things outside your profile.

A street you did not select. A conversation you did not search for. A room where nobody has optimized the agenda around your preferences. A piece of art that does not explain why it is relevant to your personal brand.

I have written before about missing real opinions on an internet full of correct answers, because the same source material eventually produces the same person with slightly improved typography.

But this feels bigger than taste.

It is about remaining interruptible.

Not distractible. I have enough tabs for that.

Interruptible.

Able to let a real place, person, object, or moment revise the internal document.

That is one of the best things a city can do. It prevents your life from becoming a recommendation engine trained exclusively on your previous decisions.

I thought the apartment was the project

The apartment still matters to me.

I want the home to feel warm, composed, useful, and ours. I want the materials to age well. I want the lighting to make 7 p.m. feel better than overhead LEDs usually permit. I want a place where friends want to stay longer, ideas have somewhere to land, and the city feels close without being inside the room screaming.

There is care in making a place a home.

The mistake would be treating the home as a perfect container that makes leaving unnecessary.

The apartment is not the whole life. It is the place the life returns to.

That distinction is changing how I think about design more broadly.

A good system should support contact with reality, not replace it.

A good writing system should help you return to the draft, not manufacture the belief.

A good work system should preserve attention for the hard decision, not fill every open hour with more work.

A good home should restore you enough to go back outside.

I wrote that ambition needs a place to live. I still believe that. But the place cannot become a bunker where the only evidence of a city is the delivery radius.

You need rooms.

You also need doors.

The Pulse Ledger

I am not going to tell you to delete your calendar, abandon your routines, and wander until the universe sends you a meaningful stranger holding a perfectly distressed copy of The Death and Life of Great American Cities.

That person would be utterly unbearable.

Systems matter. Plans matter. A home, routine, budget, and body you can trust create the stability required to be open without becoming chaos in expensive shoes.

But I have started thinking about a simpler way to review a week.

Not only: What did I finish?

Also: What made the week feel inhabited?

I call it the Pulse Ledger. It has three columns:

| Planned | Unplanned | What changed |

| What I intended to do | What interrupted or surprised me | What it gave, cost, or changed |

The point is not to romanticize every interruption. Some interruptions are just a delayed train, a bad meeting, or a stranger playing audio from their phone at a volume normally reserved for emergency broadcasting.

The point is to notice which parts of life never would have appeared on the task list…and whether the task list is leaving enough room for them to occur.

At the end of the week, mark each unplanned thing:

Prevent

Noise that scattered attention without giving anything back.

Permit

An interruption worth allowing when it appears, even if you cannot schedule it.

Pursue

A source of life you should deliberately create more surface area for… walks, people, places, art, dinners, objects, neighborhoods, conversations, or work that changes you while you are doing it.

Then ask five questions:

1. What did I encounter that I did not choose in advance?

2. What made me forget to optimize the experience?

3. What changed my mind, mood, attention, or desire?

4. What am I protecting so aggressively that nothing new can enter?

5. What deserves more open space next week?

This is not a productivity framework disguised as a permission slip to have fun.

At least I hope it is not. That would be extremely on brand and spiritually disappointing.

It is a way to make sure the system is still serving a life rather than quietly becoming the most polished substitute for one.

The city does not need to be New York

I know New York is not the answer for everyone.

Some people become more themselves in a small town, near mountains, around family, beside water, inside a workshop, or somewhere the night is… well, actually dark. Some people visit New York for 48 hours and leave with the expression of someone who has successfully escaped a kitchen fire.

Fair.

The point is not that everyone should move here.

The point is that place is not a neutral backdrop.

Your environment trains your attention. It affects what feels normal, what feels possible, who you encounter, how often you leave the house, what kinds of beauty become available, and how easy it is to drift into a life you did not consciously choose.

The useful question is not, “Is this the best city?”

It is wholeheartedly: What does this place keep asking me to become?

New York asks me to become more specific. More observant. Better dressed, ideally. Faster in some ways. Less insulated in others. More willing to leave the apartment even after I spent an unreasonable amount of time deciding what should go inside it.

It asks a lot.

That is part of why I came back.

Build the system. Then leave the house.

I am not giving up the systems.

The apartment board still exists. The writing workflow still exists. The projects have state. The routines have rules. Somewhere, a small digital agent is probably waiting to tell me that one of my recurring loops has failed a validation check.

Good.

I want the structure.

I just do not want the structure to consume all the surprise it was supposed to make room for.

So this is what I am trying now:

Build the home carefully.

Run the work cleanly.

Protect the attention.

Then close the goddam laptop and go downstairs.

The city has been there the whole time, ruining the plan.

I feel infinitely lucky.

What place makes you feel most alive, and what does it keep asking you to become? Reply and tell me. I am collecting answers.

-zc

P.S. If you want more essays about AI, ambition, taste, startup life, and trying to remain a person while building hard things, subscribe to Don’t Feed The Algorithm.

Subscribe now

Rabbit hole for the overcaffeinated

- The Death and Life of Great American Cities by Jane Jacobs — the enduring argument that healthy cities are made through density, mixed use, street life, and people paying attention to one another.

- Wanderlust by Rebecca Solnit — a cultural history of walking and the thoughts, politics, and encounters made possible by moving through the world on foot.

- Your ambition needs a place to live — my earlier attempt to figure out how to care deeply without letting work occupy every room.

- Trying to Become a Top 0.1% Human — the broader, slightly embarrassing life operating system behind this tension.

Claude Opus 5 arrived with the traditional frontier-model pageantry… benchmark charts, cost curves, and enough new superlatives to make the model you loved three weeks ago feel like a fax machine.

Anthropic says Opus 5 reached state-of-the-art results on the coding and knowledge-work evaluations it cites. The company says it is stronger at verifying its work, more careful about iterating until it succeeds, and close to Fable 5 performance at a lower cost. Those are Anthropic’s evaluations and early-access reports, not a blood oath from the universe, but the direction is interesting.

The model is getting better at long, difficult, vaguely defined work.

The obvious response is to throw it at everything.

Summarize this call. Rewrite this email. Extract these twelve fields. Name this internal project. Tell me whether this jacket makes me look like I own a motorcycle or merely maintain a concerning Pinterest board.

Most of that work does not need Opus 5.

If a stronger model costs more, I want it sitting where the judgment gets difficult: several sources disagree, the question is underspecified, the answer will change a decision, and a smooth paragraph can hide an expensive mistake.

The one Opus 5 workflow I would currently pay for is high-stakes research.

Not “research” as in asking Claude to produce a very confident answer with six blue links underneath it.

I mean a research process with a chain of custody:

- a human-owned question;

- a declared source policy;

- a claim ledger that separates fact from inference;

- a model routed to the part of the job it is actually good at;

- a clean-context challenge;

- a human sign-off attached to the final recommendation.

That last part matters more than another model leaderboard.

Better research models create a bigger authorship problem

A recent controversy around Hank Green made this tension unusually visible. Green said he had used ChatGPT to locate papers and other resources while researching a video. Complexly later said ChatGPT did not write, edit, or fact-check the disputed video. Mashable reported that some viewers were still uncomfortable with where AI sat in the research process.

I do not think the lesson is that a creator must personally discover every paper by wandering barefoot through a university library.

I also do not think “AI assisted with research” tells the audience much of anything.

Assisted how?

Did it find a paper? Read the paper? Summarize the abstract? Extract the result? Decide the result was relevant? Compare it with conflicting work? Turn a correlation into a causal sentence because the causal sentence sounded cleaner?

“Human in the loop” has the same problem.

A person clicking approve at the end does not tell you whether that person inspected the evidence or merely developed a warm feeling toward the typography.

Better models make this problem sharper. When the output is clumsy, we remember to check it. When the output is elegant, thorough, and ninety percent right, verification starts to feel ceremonial.

That is precisely when the workflow needs to become more explicit.

The model can investigate.

It cannot inherit the accountability attached to your name.

The workflow map

Here is the full system:

1. CONTRACT

Human defines the question, decision, boundaries, and proof standard.

2. SOURCE MAP

A fast model scouts. A human opens the material sources.

3. CLAIM LEDGER

The system maps every proposed claim to evidence, caveats, and a use/qualify/exclude decision.

4. OPUS SYNTHESIS

Opus 5 handles the difficult cross-source reasoning and produces a decision memo.

5. CHALLENGE + SIGN-OFF

A clean-context reviewer tries to break the memo. A human owns the final call.

This is model routing, not model worship. A current marketing platform, AirOps, recently made model and reasoning-effort selection explicit at the workflow level. The useful principle is broader than any product… extraction, deduplication, and formatting should not automatically use the same expensive reasoning tier as contradiction handling or executive synthesis.

Use the cheap, reliable tool for the cheap, repeatable work.

Bring in the expensive brain when the work becomes genuinely expensive to misunderstand.

In this deep dive, I am giving you:

- the complete AI Research Receipt working file;

- five exact prompts for running the workflow;

- the model-routing rules;

- a filled example for testing Opus 5 on competitive-intelligence synthesis;

- a 20-minute version for smaller research jobs;

- the adversarial review and human sign-off gates.

You can run it in Claude, ChatGPT, or another web-connected research tool. Opus 5 belongs at the synthesis step when the question is hard enough to justify it.

Read more

I’m going to be honest with you… you most likely do not need an AI operating system.

You probably do not need seven agents, a knowledge graph, or a dashboard showing which robot is currently summarizing the dashboard.

You need one piece of work that goes better than it did last time.

That is the smallest useful unit of AI adoption… not a tool account, prompt collection, or screenshot of a surprisingly competent answer. A workflow that takes a real input, produces something inspectable, passes a check, and helps you do actual work.

Twenty minutes is not enough to automate a company.

It is enough to stop treating AI like a slot machine.

This page is my endeavor to create the front door to the practical side of Don’t Feed The Algorithm.

Pick the problem that sounds most like yours, follow the timed setup, and build one workflow before you begin collecting more advice about workflows.

Choose your path

Do not choose based on which model currently has the most emotionally intense leaderboard discourse.

Choose based on the job.

Path 1: I have a messy job I need AI to help complete now

Choose this if you have a real outcome and a pile of source material:

- customer feedback that needs to become a roadmap recommendation;

- research that needs to become a decision;

- campaign inputs that need to become a brief;

- founder chaos that needs to become a 30-day plan;

- account evidence that needs to become careful outreach;

- weekly notes that need to become an operating review.

Start with 13 Fable 5 Prompts I’d Actually Use.

That paid working file gives you thirteen copy-ready jobs across marketing, product, engineering, sales, customer success, operations, recruiting, research, writing, and knowledge systems.

Choose this path when: the work matters now, has several inputs, and should end in one usable artifact.

Path 2: I want AI to help me build or change software

Choose this if the output is code, a product feature, a design change, or a tested build.

Start with Steal My 5 Best Claude Code Workflows.

That paid manual separates five jobs people usually collapse into “build this”:

1. interview the idea;

2. write the implementation plan;

3. build with separate specification and quality reviews;

4. fan out exploration, then converge;

5. verify the real user path and preserve what the repository learned.

Choose this path when: vague direction could create expensive code, and “the test passed” is not enough proof that the product works.

Path 3: I have a good AI task that keeps starting from zero

Choose this if you have already done the job once and expect to do it again:

- weekly customer-signal synthesis;

- recurring content opportunity research;

- a Friday operator review;

- launch readiness;

- campaign analysis;

- market monitoring;

- any recurring process where explaining the context again is becoming its own part-time job.

Start with The 5-File Claude Fable System I’d Use to Stop Starting From Zero.

That paid working file gives the job five durable parts:

JOB

SOURCES

GATES

STATE

REVIEW

Choose this path when: the first run was useful, but the next run needs memory, boundaries, verification, and a reason to exist again.

The three-path chooser

If you are still deciding, use this:

| Your situation | Start with | Your first artifact |

| “I need help completing a complex knowledge-work job.” | Path 1 | Brief, recommendation, plan, research synthesis, or operating review |

| “I need AI to build or change software safely.” | Path 2 | Approved design or implementation plan before code |

| “This useful job repeats, but every run forgets the last one.” | Path 3 | Five-file workflow contract and first saved state |

If two paths fit, begin with the earlier failure.

A recurring workflow built around a badly defined job will preserve the wrong thing with impressive consistency. A coding workflow without an approved product decision will implement ambiguity faster. Define the job first.

Your 20-minute setup

Open a blank note. Set a timer. Do not spend eleven minutes deciding what to call the folder.

0:00–2:00 — Pick one job

Finish this sentence:

I want AI to help me ________________________________.

Use a verb and an artifact.

Weak:

Help with marketing.

Useful:

Turn the last ten customer calls into a source-backed launch brief.

Or:

Turn this approved feature idea into an implementation plan another agent can execute.

2:00–5:00 — Name the trigger

Why is this job happening now?

TRIGGER

This workflow starts when:

[an event occurs / enough new evidence exists / I make a manual request]

A trigger prevents “use AI more” from becoming a recurring item on your goals list without ever touching work.

5:00–8:00 — Gather the minimum sources

List the material the workflow is allowed to use:

SOURCES

1.

2.

3.

Prefer primary material: customer calls, product documentation, current code, analytics, approved strategy, direct research, prior decisions, and real examples.

If the model has to guess where truth lives, the polished answer may simply hide the guess better.

8:00–11:00 — Draw the boundary

Write three lines:

AI MAY:

AI MUST ASK BEFORE:

AI MUST NEVER:

Publication, external sends, product strategy, spending, deleting, customer promises, sensitive information, and destructive code changes should not quietly become model decisions because the output arrived in a reassuring tone.

11:00–14:00 — Define the artifact

What must exist when the workflow is done?

OUTPUT

The run must create:

FORMAT

It should live as:

OWNER

The human who uses or approves it is:

A summary is not automatically an artifact. A decision brief, implementation plan, tested change, campaign brief, customer-signal table, or weekly operating review can be inspected and used.

14:00–17:00 — Define proof

Complete this:

VERIFICATION

I will know this worked when:

Useful checks include:

- every important claim links to a source;

- the build and tests pass;

- the real user path works;

- required fields are complete;

- the output changes a decision or next action;

- a human reviewer can accept, reject, or revise it;

- the workflow saves enough state to avoid repeating work.

The model saying “I successfully completed the task” does not count. That is a status update from the person being graded.

17:00–20:00 — Start the correct paid workflow

Open the path you chose:

- Path 1: choose one of the 13 ready-to-run jobs

- Path 2: begin with the discovery interview before touching code

- Path 3: create the five files and run the setup prompt

Paste in the job, trigger, sources, boundary, output, and verification standard you just wrote.

You are now more prepared than most AI pilot committees, which is a low bar but still a bar.

Send me your activation reply

Do not reply with “this was interesting.” I am trying to learn whether this helped you build something.

Hit reply and paste this:

PATH: 1 / 2 / 3

JOB:

TRIGGER:

FIRST ARTIFACT:

VERIFICATION:

HUMAN DECISION I KEPT:

DID I COMPLETE THE FIRST RUN? yes / no / not yet

WHAT GOT STUCK:

I will treat the workflow as activated only when the first run produces an inspectable artifact. Not when you click the link, save the post, or experience a temporary surge of organizational optimism.

That distinction matters because opening a tool is not adoption. Producing something useful is.

Your seven-day check-in

Set a reminder for seven days from now.

Reply to the same email with:

DID I USE THE ARTIFACT IN REAL WORK? yes / no

WHAT CHANGED BECAUSE IT EXISTED?

DID I RUN THE WORKFLOW AGAIN? yes / no / not applicable

DID I SAVE OR REVISE IT FOR THE NEXT TRIGGER? yes / no

HOW MUCH HUMAN CLEANUP DID IT REQUIRE? less / same / more

WHAT BROKE OR FELT TOO HEAVY?

WORKFLOW DECISION: keep / patch / narrow / retire

For this experiment, seven-day retention means at least one of three things happened:

1. you used the artifact in real work;

2. you ran the workflow again;

3. you saved a revised version for the next real trigger.

If none happened, that is useful information. The workflow may have solved an imaginary problem, required too much ceremony, or produced something impressive that nobody needed.

Retiring it is not failure.

Keeping a decorative AI workflow alive because you spent Sunday naming the files is failure with stationery.

What I am measuring

Because I am mildly insane I am treating this Start Here page like a product surface, not another article that receives a few likes and then goes to live peacefully in the archive.

The funnel is:

→ Start Here view

→ path click

→ paid upgrade, when required

→ completed first run

→ structured activation reply

→ seven-day use, repeat, or saved revision

The important measures are:

| Measure | Event | Denominator |

| Path click rate | Reader clicks Path 1, 2, or 3 | Unique Start Here viewers |

| Paid conversion by path | Reader upgrades after choosing a paid path | Unique clickers for that path |

| Workflow activation rate | First run creates an inspectable artifact | Unique Start Here viewers and structured replies, reported separately |

| Activation reply completion | Reader submits the structured reply | Unique Start Here viewers |

| Seven-day utility rate | Reader used the artifact in real work | Activated readers who receive/reach the check-in |

| Seven-day retention rate | Reader used, reran, or saved a revised workflow | Activated readers who receive/reach the check-in |

| Review burden | Reader reports less, same, or more human cleanup | Seven-day respondents |

I care about upgrades. Paid subscribers help me invest the time to create more working files around my workflows. Hey I just moved back to New York, gotta afford the shoebox.

But a purchase without genuine activation is completely useless.

If the paid library becomes a tasteful warehouse of templates nobody runs, I have made premium shelf space.

The better test is whether one file helps one person produce one useful artifact… and whether the system is worth returning to.

Start smaller than your ambition

There is a version of AI adoption that begins with a company brain, twelve integrations, a new governance council, and a diagram that looks like public transit for ghosts.

Sometimes that infrastructure is justified.

It is not where I would start.

Start with one job. Use real sources. Define the boundary. Require an artifact. Check the result. Save only what the next run needs.

Twenty minutes will not build the final system.

It will tell you whether there should be one.

Reply with your path and job. Seven days later, tell me whether it survived contact with work.

-zc

P.S. Paid subscribers get the implementation layer… the exact prompts, workflow contracts, setup files, verification steps, and examples behind all three paths. Free gives you the map. Paid gives you something to run.

Subscribe now

Rabbit hole for the overcaffeinated

- Anthropic: Building Effective Agents — the best constraint for this entire experiment: start with the simplest credible solution and add complexity only when it improves results.

- Claude Code documentation — the official starting point for understanding the coding environment behind Path 2.

- BJ Fogg’s Behavior Model — a useful way to think about why motivation alone does not create action; behavior also needs ability and a prompt at the same moment.

- 13 Fable 5 Prompts I’d Actually Use — Path 1 for completing one complex, source-heavy job.

- Steal My 5 Best Claude Code Workflows — Path 2 for turning product direction into planned, reviewed, verified software work.

- The 5-File Claude Fable System — Path 3 for making a useful recurring job restartable and reviewable.

Most companies do not have an AI-tool problem anymore.

They have a handoff problem wearing twelve software subscriptions.

There is a meeting bot summarizing calls. A research agent monitoring competitors. A content tool drafting posts. A coding agent building features. A CRM holding customer activity. A Slack channel collecting reactions. A project manager asking why none of this has changed the roadmap.

Each component can do something impressive.

The work between them is still mostly held together by memory, copy-and-paste, and somebody saying, “I thought marketing owned that.”

That is where graph engineering becomes useful.

I recently wrote about graph engineering as the discipline above the prompt. Prompt engineering shapes one call. Context engineering decides what that call should know. Graph engineering designs how models, tools, code, evidence, people, approvals, and actions coordinate over time.

The theory is clean:

Nodes do the work. Edges decide what happens next.

The company version is messier.

Customer feedback should become evidence. Evidence should change a decision. A decision should create an owner and an artifact. Marketing should be able to trace a claim back to proof. Product work should preserve why it started. Performance should update the next brief instead of dying inside a dashboard nobody opens twice.

A useful company graph connects those moments.

Not as one giant autonomous brain.

As a small set of inspectable workflows that preserve state, route work, enforce gates, and leave receipts.

The company graph in one screen

Most of the workflows in this guide share the same spine:

→ signal

→ preserve evidence

→ classify and route

→ produce a recommendation or artifact

→ verify against a real gate

→ human approval when consequential

→ execute

→ measure the outcome

→ update durable knowledge

This is not a complicated idea. It is also not how most AI systems behave.

The default AI workflow is closer to:

→ ask

→ receive impressive answer

→ paste somewhere

→ lose the source

→ repeat next Tuesday

A graph becomes worth building when the work has multiple meaningful stages, branching, long-lived state, approval boundaries, recurring failure, or consequences somebody will eventually have to explain.

If one prompt and a checklist solve the problem, use one prompt and a checklist. Complexity is not a business outcome.

What is inside the paid playbook

I built five starter graphs around the places lean teams lose the most operating context:

1. Signal-to-Action Graph — turns customer, market, sales, and competitive signals into routed recommendations and owned next actions.

2. Evidence-to-Content Graph — turns research and customer evidence into source-backed marketing without letting AI invent proof.

3. Decision-to-Execution Graph — prevents decisions from becoming meeting residue by connecting the rationale, owner, approval, artifact, and review trigger.

4. Customer-to-Product Graph — turns feedback into evidence-backed product opportunities without treating every loud request like strategy.

5. Weekly Company Learning Graph — compiles what changed across the business into priorities, open questions, and updates to the system itself.

For each one, the paid section includes:

- the exact node map;

- trigger and state contract;

- what belongs to code, a model, an agent, an evaluator, or a human;

- approval gates;

- failure and retry rules;

- the receipt each run should leave behind;

- a starter instruction you can paste into an AI tool;

- the metric that tells you whether the graph is helping;

- the condition for deleting it.

I also made a Company Graph Starter Kit with the shared case template, YAML state file, node contract, edge contract, weekly review, and 20-point readiness scorecard.

Read more

I opened a new workspace this week and saw five channels in the sidebar.

One for my core job. One for a specific product GTM initiative inside that job. One for a software I’m building. One for this newsletter. One for Council Fire, the sustainability firm my dad founded and I also work with.

Yeah… I’ve got a lot going on. So, naturally, I’m efficiency obsessed. No… like it’s getting to be a bit of a problem, obsessed.

Anyways, I digress.

Each channel had a purpose, current goals, source material, operating rules, and a different combination of AI agents inside it.

Hermes could move across all five. Claude was allowed into one product channel to inspect the repository and challenge technical decisions. Council Fire had a completely separate Claude identity grounded in its own company brain. My newsletter channel had no coding agent at all because my essays do not need a robot opening pull requests in the middle of a sentence.

There was one human in every channel.

Still me. A devastating failure of delegation.

But this did not feel like opening five chat windows. It felt like opening a small company Slack where every room had its own AI team, project memory, goals, and rules about what the agents could touch.

That distinction is the whole thing.

The experience we’ve all grown accustomed to with AI tools is that they give you a brilliant person with no desk. You start a chat, explain the company again, paste the source material again, clarify which project you mean, remind the model what it promised yesterday, and hope it does not confuse your newsletter with your employer’s product launch.

I wanted the work to have somewhere to live.

So I built my own private agent workspace. Obviously.

The tool is called Buzz

Buzz is an open-source, self-hostable workspace from Block where humans and AI agents can share channels, threads, canvases, workflows, repositories, and an audit trail.

It looks enough like Slack that your muscle memory works. Underneath, it runs on a relay built around signed Nostr events. Messages, reactions, approvals, workflow steps, canvas changes, and agent activity are written into the same event log. Humans and agents use the same identity model.

The practical part is simpler… agents become actual channel members.

They have their own identity. They only see the rooms they have joined. They can be mentioned in a thread. Their work stays attached to the project instead of disappearing into a private model conversation nobody else can find later.

Buzz also ships an ACP harness that can connect compatible agents such as Claude Code or Codex to a room. ACP, the Agent Client Protocol, is the pipe between the workspace and the agent runtime. The agent hears a mention, receives the relevant thread context, does its work, and replies in the same place.

At least, that is the clean version.

The actual version involved Docker, Colima, a local relay, multiple cryptographic identities, launch services, one Python script written specifically to stop two AIs from becoming pen pals, and an embarrassing amount of time learning which flavor of WebSocket URL a Rust binary considered emotionally valid.

I now run the entire thing locally.

The relay only listens on my machine. Buzz Desktop is the human interface. Hermes connects as the coordinating agent. Two separate Claude runtimes connect as narrower specialists.

The stack matters less than what it forced me to decide.

A channel is not just a topic

My first instinct was to recreate my folder structure as channels.

Work. Writing. Product. Council Fire. Maybe research. Maybe a special room for every launch. Maybe seventeen little departments so I could feel like the CEO of a company that consisted mostly of YAML.

That would have been agent underlord (see what I did there?) cosplay.

A useful channel needs a durable difference in at least one of these things:

- its outcome;

- its canonical context;

- the agents required;

- the actions those agents can take;

- the approval rules;

- the work volume.

I ended up with five rooms:

| Channel | What lives there | AI team |

| Cohley | Cross-product PMM decisions, evidence, enablement, and approved artifacts | Me + Hermes |

| Product Seeding | One focused product/GTM initiative inside Cohley | Me + Hermes |

| Trovance | Product strategy, roadmap, market evidence, editorial work, and repository-backed technical decisions | Me + Hermes + Claude Code |

| Personal Substack | Editorial ideas, drafts, growth decisions, and distribution | Me + Hermes |

| Council Fire | Company strategy, marketing, business development, editorial work, and institutional knowledge | Me + Hermes + a separate Council Fire Claude |

That table is not interesting because I made five channels. Slack has been bravely handling that level of information architecture since 2014.

The interesting part is that the agents are different in each room on purpose.

Claude Code is useful in the Trovance room because product strategy there regularly collides with a large live repository. It can inspect implementation reality, find contradictions between a roadmap and the code, and challenge sequencing without being allowed to casually edit or deploy anything.

It does not belong in my Product Seeding room by default. Most of that work is positioning, customer evidence, adoption, enablement, and product judgment. Adding a coding agent because “more agents” sounds impressive would create another mouth to feed context into.

Council Fire needed a different answer. Its important context does not live in my personal Obsidian vault or the Trovance repository. It has a separate company brain with its own strategy, methodology, client sensitivities, product ideas, and institutional memory. So Council Fire got a separate Claude identity, a separate runtime, a separate working directory, and membership in exactly one channel.

Same underlying model family. Different company. Different brain. Different key. Different permissions.

That is much closer to how you would onboard a human teammate than how most people configure a chatbot.

Every room gets an operating contract

The most useful feature in the setup is not the agent.

It is the canvas pinned to each channel.

A canvas explains:

- why the room exists;

- the current outcome;

- its workstreams;

- the canonical files or knowledge base;

- who belongs there;

- how to ask for work;

- what a good response must include;

- where final artifacts should go;

- which actions need human approval.

The Trovance room, for example, is allowed to cover product strategy, positioning, market evidence, editorial work, implementation, and launches. It names the relevant Obsidian notes and repository. It tells Hermes to frame product and customer tradeoffs. It tells Claude to inspect architecture and feasibility. It tells both of them that publishing, deployment, production changes, spend, and binding roadmap promises still belong to me.

The request labels are intentionally boring:

intake:

analyze:

draft:

decide:

execute after approval:

publish after approval:

Boring is good here. “Decide” and “execute” are different verbs because they are different jobs.

A recommendation can be excellent without granting permission to act on it. A thumbs-up reaction can mean “I saw this,” “I agree,” “good point,” or “my finger slipped while holding groceries.” It should not silently become authorization to deploy software or email a customer.

The room contract keeps the social layer legible for both humans and agents.

The memory does not live in the chat

This was the first painful correction.

I wanted to connect the Claude Project I already used for Council Fire. It had months of useful conversations and company context. Surely I could invite that Claude into the new room and keep going.

Nope.

“Claude” is not one continuous coworker floating between interfaces with a tiny briefcase of memories. The hosted Claude.ai Project, Claude Code, and a local ACP agent are different runtime surfaces. Private chat history does not magically transfer because the logos match.

The only reliable shared memory is the context you externalize.

Council Fire already had a local company brain: structured files, a knowledge map, operating instructions, strategy, products, methods, and durable conclusions from previous work. I rooted the new Claude participant there. Now the hosted Project and the Buzz agent can use the same institutional context when that context has actually been written down.

Hidden chat history remains hidden.

This is annoying for approximately twelve minutes. Then it becomes a really useful design principle.

If a decision matters to the company, it should not exist only inside a private conversation with a model. It should be promoted into the company brain, repository, decision ledger, or another canonical system.

The chat is where the thinking happens.

The company memory is where the conclusion survives.

I have already written about using Obsidian to give AI durable memory and building a one-person company with a real operating system.

Buzz added the missing social layer: the place where a project can discuss, challenge, approve, and preserve work without confusing conversation for truth.

I let the agents talk to each other, but only twice

The fastest way to make an agent workspace feel futuristic is to let the agents converse autonomously.

It is also a fantastic way to produce a very expensive improv scene.

I wanted Hermes and Claude to collaborate in the Trovance room. Hermes knows the broader product, market, and business context. Claude can inspect the repository and challenge what the current architecture can support. Together, they should be better than either alone.

But “Hermes and Claude should discuss the roadmap” is not an operating model. It is an invitation to keep endlessly replying.

So we built a bounded contract:

Zach introduces a decision

→ Hermes frames the objective and contributes a point of view

→ Claude gets one scoped, read-only inspection

→ Hermes may ask one final clarification

→ Claude responds

→ Hermes synthesizes agreements, dissent, evidence, and decisions for Zach

→ STOP

Two Claude turns. Maximum.

The rules we all wish we could implement at the next all-hands, be honest.

A deterministic helper tracks the collaboration ID, round number, request event, reply event, content hash, and terminal state. A third round is rejected. Claude-authored messages do not automatically wake Hermes. The initiating Hermes run waits for the exact expected response and then returns to moí.

The system does not rely on a prompt that says “please don’t loop.” The routing enforces the stop for me.

We tested it on a real long-term product-roadmap discussion. Hermes brought the market and product framing. Claude inspected the live repository, found that a newer six-month plan superseded much of the older long-term roadmap, separated features that were coded from those actually exercised in production, and caught that an important retained product specification was sitting untracked in the working tree.

Hermes disagreed with parts of Claude’s recommendation and sent one final challenge. Claude pushed back on the number of near-term feature bets because the measured verification capacity could not support them. Hermes accepted that correction, preserved the remaining disagreement, and opened a Roadmap Council thread for me with the decision slate.

Then they stopped.

No one wrote code. No one changed the roadmap. No one declared consensus because two language models had achieved the machine equivalent of nodding thoughtfully.

The output was a better decision surface.

That is the kind of agent collaboration I trust: bounded, inspectable, willing to preserve dissent, and terminal by design.

Also, yeah it was pretty f*cking cool to witness.

The security model is less magical than the UI

Giving agents their own channels feels like a clean permission boundary.

It is one boundary. It is not every boundary.

Channel membership determines which Buzz conversations an agent can see. It does not automatically control every file the process could access on my Mac. A read-only instruction in a system prompt is a policy. A symlink to an Obsidian vault is not an operating-system-enforced read-only mount. “Plan mode” reduces risk, but it is not the same thing as a filesystem sandbox.

I run the relay locally and do not expose its port publicly. Every visible agent has a separate cryptographic identity. Each Claude runtime is limited to one room, mention-only, with no autonomous heartbeat. External messages, publishing, deployment, production changes, spending, destructive actions, and sensitive claims require me.

That is enough for the current pilot.

It is not the final form of a high-security enterprise deployment. Stronger versions should use actual filesystem controls, read-only mirrors, brokered retrieval, more granular credentials, and independently enforced action policies.

This is the part agent demos tend to skip because “the prompt tells it not to” fits better on a slide.

The prompt matters. The process boundary matters a whole heck of a lot more.

What changed once the projects had rooms

The immediate benefit was not that the agents became smarter.

I repeated myself less.

A new Product Seeding question starts inside the Product Seeding room, where the current objective, response contract, canonical Cohley context, and approval rules already exist.

A Council Fire question begins inside a company environment with its own knowledge.

A Trovance roadmap decision can pull technical evidence from the repository without giving that same coding agent a permanent seat in my newsletter.

More importantly, I can see the work as work.

A thread holds the request, evidence, challenge, recommendation, approval, and receipt. The room canvas holds the standing contract. Obsidian or the project repository holds the durable truth. GitHub holds implementation history. The publishing system holds the thing that actually shipped.

Buzz is not replacing all of those systems.

It is becoming the place they coordinate.

That is a better mental model for AI at work. The model is not the company. The chat is not the memory. The channel is not the filesystem permission. The recommendation is not the approval. The plan is not the shipped artifact.

The interfaces can feel unified without pretending the underlying jobs are the same.

Build your own agent channel contract

You do not need Buzz, Nostr, ACP, multiple Claudes, or a weekend relationship with Docker to use the useful part.

Pick one recurring project and write this contract before inviting an AI into it:

CHANNEL

What durable body of work belongs here?

OUTCOME

What should become observably different?

CANONICAL CONTEXT

Which files, notes, repositories, dashboards, or sources are authoritative?

What private chat context is explicitly not shared?

AGENT ROLE

What recurring responsibility justifies a visible agent?

What does the human still own?

TRIGGER

Does the agent act only when mentioned, on an approved schedule, or after a specific event?

ALLOWED SCOPE

What may it read, analyze, draft, or change?

Which people or agents may assign it work?

PROHIBITED ACTIONS

What requires explicit approval?

Publishing, external communication, deployment, spend, sensitive claims,

destructive changes, customer data, or binding decisions?

OUTPUT CONTRACT

What evidence, paths, risks, recommendation, verification, and decision should it return?

STOP RULE

What limits turns, retries, time, cost, or autonomous continuation?

RECEIPT

What should remain after the work: event ID, decision, artifact, test result,

approval, or next review date?

Then run three real work items before adding another agent.

If the AI still needs the same context explained every time, fix the context source.

If the agent produces useful work but nothing changes, fix the handoff.

If review cannot reject or redirect the result, fix the gate.

If no one can explain why the agent is permanently in the room, remove it.

The agent should earn its channel membership.

The company Slack is becoming the company itself

Slack was built around a simple idea… work improves when the right people can gather around a shared project, see the history, and coordinate what happens next.

AI does not make that model obsolete. It makes the design more important.

Agents need rooms. They need identity. They need access to the right memory and exclusion from the wrong one. They need clear jobs, inspectable handoffs, hard stops, and a human who remains responsible when the output touches reality.

I thought I was building a nicer interface for my collection of AI tools.

What I actually built was an org chart with enforceable edges.

Not a fake company full of synthetic employees. A small operating environment where humans and agents can gather around real work without pretending every model should know everything or do anything.

The agents now have channels, projects, goals, context, and coworkers.

I still have the final approval button.

Seems fair. They have not even once offered to cover health insurance.

Would you run your work through an agent Slack like this? Reply and tell me the first channel you would create, which agent belongs there, and the one thing you would never let it do without you.

-zc

P.S. If you want more field notes from the point where AI stops being a chat and starts becoming a company system, subscribe to *Don’t Feed The Algorithm*.

Subscribe now

I’ll keep sharing the useful architecture, the parts that fail, and the controls that make the whole thing less ridiculous.

Rabbit hole for the overcaffeinated

- Buzz on GitHub — the open-source workspace behind this experiment, including the relay, desktop app, CLI, agent harness, workflows, and signed event model.

- Buzz ACP harness — how compatible agents listen for mentions and reply inside channels.

- Agent Client Protocol — the open protocol connecting agent runtimes to clients like Buzz.

- Anthropic: Building Effective Agents — a useful counterweight to the usual agent slop… start simple, add complexity only when it improves the result.

- Your AI Board of Advisors Is Useless Unless It Keeps Minutes — my earlier version of the argument that agent discussion needs decisions, dissent, next actions, and review triggers.

- How to Build a One-Person Company With AI — the wider operating model this workspace now makes more tangible.

I’ll be honest… this one won’t be the most “fun” article you’ve read from me. It will, however, be incredibly helpful and give you an exact template & prompt breakdown for how to create, manage & execute a Creative Memory OS.

Here’s what to expect…

- an Obsidian folder structure

- a capture note template

- a source bank template

- an idea room template

- AI prompts for turning notes into outlines, draft briefs, revision memos, and paid/free asset plans

- a low-energy writing mode

- a weekly review ritual

- a filled example you can model

Use what helps. Ignore what feels like homework wearing a little productivity vest.

The goal is not to build a perfect second brain.

The goal is to make writing easier to resume.

How to use this

If you are starting from scratch, do not implement everything at once.

That is how a creative system becomes a procrastination habitat with tasteful folders.

Start with three pieces:

1. One capture inbox for raw material.

2. One idea room template for active pieces.

3. One weekly ritual that moves captured thoughts toward finished work.

Then add source banks and AI prompts as the system earns them.

A good creative system should meet you where your life actually is. Not where your fantasy self lives after finally becoming a person who stretches, meal preps, and names files correctly.

Read more

I spent the other day doing the extremely normal Sunday activity of investigating whether Andrej Karpathy had secretly invented an entire engineering discipline over the weekend.

The internet said he had released a “Graph Engineering Manual.” People were posting screenshots. The phrase sounded important. I was approximately four minutes away from reorganizing my professional identity around it.

There was one small problem.

Karpathy did not write the manual.

The document itself says it was independently compiled, not affiliated with Karpathy, and not endorsed by him. The internet had taken a useful third-party synthesis, attached a more famous person to it, and sent it down the timeline before anyone opened page two.

So, naturally, I started pulling on the thread.

The attribution was wrong. The underlying idea was not.

Karpathy has written and built several graph-shaped systems: autoresearch, where an agent changes code, runs a fixed experiment, measures the result, and keeps or discards the change; LLM Council, where models answer independently, judge one another anonymously, and feed a final synthesis; and his LLM Wiki concept, where raw sources become a persistent, interlinked knowledge base that gets queried, updated, and linted over time.

He also described context engineering as only one part of a much thicker software layer that has to break work into control flows, pack context, dispatch the right models, handle verification, manage parallel work, and apply guardrails. That is not the same thing as claiming the phrase “graph engineering.” It is the system-design problem the phrase is trying to name.

LangChain published its own direct treatment of graph engineering last week.

Its cleanest version is almost annoyingly simple:

Nodes do the work. Edges decide what happens next.

I kept thinking about that sentence because it described the exact problem I had been creating for myself.

I did not need another agent.

I had plenty of agents.

I needed to know how the work moved between them without losing the source, the decision, the approval, or the reason any of it existed.

Prompts manage a call. Graphs manage the work.

Prompt engineering asks: what should this model do?

Context engineering asks: what should this model know right now?

Graph engineering asks: how should models, tools, code, memory, evaluators, humans, and external actions coordinate over time?

That last question becomes important the moment an AI workflow has more than one meaningful stage.

Research has to become a decision. A decision has to become a brief. A brief becomes a draft. A draft needs a truth check. A truth check may send it back to research. A human may approve, reject, or revise it. Publication creates a receipt. Performance creates new evidence. That evidence should change the next decision.

You can put all of this inside one heroic prompt if you enjoy living dangerously.

The model may produce something impressive. It may even produce the right answer.

But where does the state live? What happens when a source is missing? Which action requires approval? Can the workflow resume tomorrow without rereading a 40,000-word chat? If two agents work in parallel, what happens when they disagree? Who is allowed to publish? What stops the revision loop from spending $83 polishing a sentence nobody needs?

The prompt can describe those rules.

The graph makes them real.

I already had the nodes

My current AI setup is embarrassingly elaborate for a person who still loses his sunglasses while wearing them.

I use Hermes as an operating layer. Obsidian holds durable knowledge. Different agent profiles handle different kinds of work. Skills contain reusable methods. Scheduled jobs monitor sources and prepare drafts. Repositories hold code and product state. Telegram is where I approve consequential actions or discover that one of my robots has become emotionally invested in a CSV.

These were all useful nodes.

The edges were mostly implied.

A research session might create a strong note. That note could inform a product plan. The plan might become a coding handoff. Feedback would arrive in another session. Then two days later I would remember the original idea but not which source supported it, whether I had approved implementation, or where the final artifact lived.

The system could do impressive work. It was bad at explaining its own history.

That is the difference between a pile of AI capabilities and an operating system.

A pile has tools.

A system has state, transitions, boundaries, and receipts.

What we built yesterday

We built a small file-backed work graph across Hermes and Obsidian.

Not a glossy graph canvas. Not twelve new agents with names from Greek mythology. Not a dashboard that needs its own customer success manager.

A boring, inspectable spine for important work:

Important source or conversation

→ captured work case

→ triage

→ compiled knowledge

→ decision or output candidate

→ human approval when consequential

→ execution

→ artifact

→ feedback or measurement

→ durable learning

→ close or reopen

Each meaningful piece of work can become a Work Case. The case records what triggered it, which evidence it used, why it took a particular route, who approved the consequential step, what artifact came out, what happened afterward, and where the learning was applied.

The first version has 13 states and 17 typed relationships. Current state lives in JSON. Every meaningful change creates an append-only event. Obsidian gets a readable case note and index. Approval becomes an explicit receipt rather than something inferred from a model saying, “Sounds good.”

It is intentionally a single-writer system right now. It does not pretend to coordinate parallel processes safely before file locking and conflict rules exist. It also does not control my existing automations yet. We are running a small manual pilot across a handful of real cases before promoting anything into recurring infrastructure.

That last part matters.

A graph can make a good workflow more reliable. It can also make a bad workflow repeat itself with tremendous organizational confidence.

The first real case

We dogfooded the graph on a product I am building for the agentic web (more coming soon).

Most AI-visibility products diagnose a problem… your brand was absent from an answer, a competitor appeared, or a source was cited instead of you.

Diagnosis is useful. It is also where a lot of products stop.

The harder system is what happens after the score:

buyer question:

→ live AI answer

→ citation or evidence gap

→ recommended intervention

→ proof requirement

→ content or product work

→ human approval

→ publication

→ verification

→ later observation

We turned that into a detailed implementation handoff grounded in our current repository. It specified the user-facing case object, state transitions, evidence lineage, approval gates, failure paths, tests, rollout stages, and the systems that should be reused instead of rebuilt.

The artifact was 41,754 bytes long, which is not a quality metric but does prove that I spent Sunday exactly as god intended.

More important: the handoff preserved the distinction between “specified” and “implemented.” It could prepare a build. It could not quietly decide that preparation counted as approval to change the product.

The Work Case recorded the source research, the product specification, the coding handoff, my approval of the handoff, the fact that implementation remained a separate decision, and the feedback that became learning for the broader system.

The graph did not make the thinking smarter by itself.

It made the thinking harder to lose, misroute, or overstate.

The useful part is the edge

Most AI demos obsess over nodes.

Add a researcher. Add a writer. Add a critic. Add a strategist. Add a chairman. Add a small, fictional org chart until your laptop resembles a consulting firm trapped inside a snow globe.

The difficult question is whether the handoffs are real.

If the writer does not consume the researcher’s evidence, there is no research-to-writing edge. There are two tasks that happened near each other.

If the reviewer never changes the draft or controls promotion, review is theater.

If feedback gets stored but never changes a prompt, rule, source, decision, or next run, there is no learning loop. There is a folder named “feedback.”

A real edge means the destination consumes something meaningful from the source:

- evidence;

- a state change;

- an approval;

- a decision;

- an artifact;

- a side-effect receipt.

This became my favorite test from the whole exercise:

What becomes impossible, invalid, or different if this connection disappears?

If the answer is “nothing,” you probably drew chronology, not dependency.

Delete the fake edge.

Graph engineering is controlled allocation of agency

The phrase sounds like it belongs inside a graduate course taught in a room with no windows.

The practical idea is much friendlier.

Not every node should be an agent.

Use deterministic code for thresholds, permissions, duplicate prevention, schema validation, spend limits, and anything that must behave the same way every time.

Use model calls for fuzzy classification, synthesis, drafting, interpretation, and other work where judgment is useful but bounded.

Use open-ended agents when the path genuinely cannot be specified in advance and the result justifies the additional cost and uncertainty.

Use evaluators when something needs an independent check.

Use humans for taste, disputed truth, public claims, publication, money, sensitive information, destructive actions, and decisions where “the model felt confident” would be a terrible incident report.

Anthropic’s guidance on building effective agents makes the same practical argument from another direction… begin with the simplest solution and add complexity only when it measurably helps.

The goal is not to put every business process inside a graph.

The goal is to stop pretending that a single chat window is an adequate control plane for work that has evidence, memory, branches, approvals, failure, and consequences.

The graph engineering test

You do not need LangGraph, a graph database, or a new title on LinkedIn to use this idea.

Take one recurring AI workflow and answer the questions below.

1. OUTCOME

What should become observably different when this workflow succeeds?

2. BASELINE

What is the simplest credible version: a checklist, one model call, or one bounded tool loop?

3. STATE

What evidence, decisions, artifacts, and progress must survive after the chat ends?

4. NODES

Which steps belong to deterministic code, model judgment, an open-ended agent, an evaluator, a human, or an external action?

5. EDGES

What does each destination actually consume from the previous step?

If it consumes nothing, remove the edge.

6. GATES

Which transitions require a deterministic rule or explicit human approval?

7. FAILURE

What happens when evidence is missing, a tool times out, an evaluator rejects the work, or a human does not respond?

8. RECEIPTS

What should the system preserve so somebody can explain what happened later?

9. STOP RULE

What limits retries, cost, time, revision, and autonomous action?

10. VALUE TEST

Does this graph beat the simpler baseline on outcome, reliability, cost, speed, or operator attention?

If not, delete it.

That final question is the one most graph diagrams mysteriously forget.

Complexity has a way of looking like progress when rendered in Mermaid.

Sometimes the right graph has three nodes. Sometimes the right system is one good prompt and a human checklist. Sometimes persistence matters more than parallelism. Sometimes the “agent” should be a Python function with excellent boundaries and no opinions.

Graph engineering earns its name when the topology improves the work.

Otherwise it is workflow fan fiction.

The shift above the prompt

I still care about prompts. I still care about context. A badly instructed node inside a beautiful graph is still bad.

But the object I am designing has moved up one level.

I used to ask: how do I get a better answer from the model?

Now I ask:

- What should happen before this call?

- What evidence should it receive?

- What is it allowed to change?

- Who checks the output?

- What happens when it fails?

- What state should survive?

- Which decision stays mine?

- How does the result change the next run?

Those questions are less magical than prompt tricks.

They are also how the magic survives contact with Tuesday.

This is why graph engineering feels like a useful emerging term, even if the internet introduced it through a document credited to the wrong person.

It gives us language for the thing between a good model call and a dependable AI-native company.

The model is one component.

The product is the system around it.

What is one AI workflow in your life or company that works brilliantly once and then forgets how it got there? Reply and tell me. I want to know where the missing edge keeps showing up.

-zc

P.S. If you want more notes from the part where AI stops being a demo and starts becoming management, subscribe to Don’t Feed The Algorithm.

Subscribe now

I write about the workflows, failures, product decisions, and occasional Sunday identity crises involved in making these systems useful.

Rabbit hole for the overcaffeinated

- 3 Years of Graph Engineering with LangGraph — the clearest direct articulation of the emerging term and why production agent systems need explicit state and transitions.

- Anthropic: Building Effective Agents — the necessary anti-hype constraint: start simple and earn additional complexity.

- Karpathy’s autoresearch — a tiny, measurable autonomous loop with an immutable evaluator, fixed budget, persistent Git state, and a keep/discard rule.

- Temporal on durable workflows — useful when you want to understand why state, event history, replay, and idempotency become product concerns.

- Your AI Board of Advisors Is Useless Unless It Keeps Minutes — my earlier argument that an AI conversation becomes useful when it leaves behind a decision, dissent, next action, and review trigger.

- How I Use Claude Code to Build Apps Without Pretending I’m an Engineer — the human responsibility layer behind my coding-agent workflow.