Written as the companion to my lightning talk at ClawCamp SF, Saturday 15 August 2026. If you just scanned the code from the room: this is the whole argument, with the sources.

Slides from the talk: https://xteamos.exponentialos.io/deck/

A survey of 2,444 companies put a number on something most engineering teams already feel.

For every dollar spent on AI tokens: 44 cents goes to fixing bugs the AI created. 27 cents to rewriting its code. 11 cents to review and merge delays.

Eighteen cents reaches production.

That number went around as “82% of your AI spend is wasted,” and I want to deal with the objection before I use it, because the objection is good.

The number is directionally right and numerically dubious

The study comes from Entelligence, a company that sells tooling for the exact problem the statistic describes. The methodology is self-reported. The 2,444 companies likely include free-tier accounts. A forensic teardown of the claim landed on the right verdict: directionally right, numerically dubious.

The teardown’s sharpest point is the one nobody quoting the stat mentions: pre-AI software development already spent 75–80% of effort on maintenance and debugging. So 82% isn’t a shocking new tax. It’s roughly the historical baseline wearing a new hat.

Which means the interesting question isn’t “how much is wasted.” It’s what actually changed.

What changed: generation outran review

Rework has always been most of the work. What’s new is the ratio between how fast you can produce code and how fast anyone can check it.

CodeRabbit measures AI-generated changes carrying roughly 1.7× more issues than human-written ones. Lightrun’s 2026 report found 43% of AI-generated code still requires manual debugging in production — after it passed quality checks.

Sit with that second one. Not “before review caught it.” After.

So the bottleneck was never cost per token. It’s review throughput, and every model upgrade makes the imbalance worse, because generation scales and human review does not.

That reframes what a quality gate is. A gate isn’t a tax on velocity. A gate is the only thing that raises the share of your spend that reaches the product. Yield, not savings.

Three things are quietly eating that yield. The first you can fix before you write a line, and the last is the one nobody says out loud.

Leak zero: you specified it wrong

Before routing and before context, there is a cheaper failure. The most expensive bug is the one you specified wrong, because everything downstream then executes the wrong thing faithfully and on budget.

You know what you want. Getting it into words precise enough for a model to act on is the actual work, and it is where the time and the tokens go. A vague request does not fail loudly. It returns something plausible, you read it, you realise it is not what you meant, and you ask again in slightly different words. Do that three times and you have paid for four answers to get one. A meaningful share of the 44 cents starts there, before a single routing or context decision.

Neither of the other two fixes helps you here. You can send a badly specified task to the cheapest capable model, with a perfectly curated window, and still get back code you have to rewrite.

The fix is unglamorous. State the outcome rather than the steps: what must be true when it is done, who it is for, and what would make it wrong. Then leave the how to the model. That is most of it.

I automated this for myself, because I was never going to do it by hand on every request. The prompt gets rewritten before it runs and I see both versions, so the sharpening happens inside the ten seconds I was going to spend anyway rather than in a fourth attempt.

Leak one: you route every task as if it were the hardest one

You get access to a frontier model. It’s good at everything, so you send it everything — file reads, git operations, deploys, browser automation, boilerplate tests, and the two decisions a day that actually need judgment.

Those are not the same task. You are paying judgment prices for clerical work, and you hit the rate ceiling by mid-afternoon because you spent the budget on git status.

The fix is routing by task class rather than by habit:

1) Deterministic work — deploys, git, file operations — goes to a small fast model. On current public pricing that’s roughly 20× cheaper than the frontier tier.

2) Browser automation and large reads go to a cheap high-context model, roughly 50× cheaper. This one matters more than it sounds: a single page snapshot can dump an entire DOM into your context, and you pay for those tokens on every subsequent turn.

3) Code generation goes to a code-specialised model.

4) The expensive model does one thing: judgment. Specs, gates, synthesis. That’s it.

None of that is controversial. It’s the second leak that people argue with.

Leak two: a bigger context window makes your agent worse

Everyone has been told to start a new session when things go sideways. Almost nobody explains why.

It’s a cure prescribed without a diagnosis, and once you have the diagnosis, the advice turns out to be the crudest possible intervention.

Why a fresh session feels smarter

Not because it’s emptier. Because the wrong turns are gone.

Every dead end you explored is still sitting in that window. The three incorrect things you told it about your schema two hours ago are still there, still being conditioned on. A fresh session doesn’t give the model more room to think — it removes the accumulated wrong answers.

That distinction kills the naive fix. Compressing by volume doesn’t help if you compress the wrong turns along with the right ones. You end up with a tidy summary of your own mistakes.

The research says it’s worse than dilution

Two findings, both well-established, both counterintuitive.

Position matters, badly. Liu et al., Lost in the Middle: How Language Models Use Long Contexts (Stanford, published in TACL), found performance is highest when relevant information sits at the beginning or end of the context and degrades significantly when the model must retrieve from the middle. Put the important thing in the middle of a long window and you have hidden it.

Irrelevant context isn’t neutral — it competes. Chroma’s context-rot work and the GSM-DC benchmark both find that models are meaningfully degraded by distractors, and that semantic similarity drives decay more than length does. A distractor that looks like the answer costs you far more than one that obviously doesn’t. A single distractor already degrades baseline; several compound it.

And then the finding that should change how you think about this entirely:

Models performed better on shuffled context than on logically coherent context — across 18 models. Coherent documents share terminology and structure, which makes them better distractors.

Read that again, because it inverts the instinct everyone has. The more relevant-looking the material you stuff into the window, the more damage it does. “Just give it all the related files, it’s all connected” is precisely the wrong move.

“It fits” is not the same as “it helps.”

The architecture: the smallest thing that does the job

The other two leaks have the same shape, and the same fix.

Sharp focus. Keep the working context deliberately small. Not as a limitation you’re working around — as a design choice.

Long-term memory. Everything else lives in an index outside the window. The agent doesn’t need to hold it. It needs to know where it is.

Just-in-time injection. Hydrate only the relevant slice, at the moment the task needs it. When the session ends, distil what was learned back into the index.

That’s what I run daily. The agent doesn’t carry everything. It carries the right thing at the right moment and knows where the rest lives.

Which makes “start a new session” look like what it is: amputation. It works. It also throws away everything you learned getting there. That’s only a rational trade if you have no memory layer — which, for most people giving the advice, is true.

Two better techniques:

Self-compress on your own schedule. The critical word is your. Auto-compaction fires when the system hits a limit, which is precisely the moment you have least control over what survives. Compress deliberately, at a natural boundary, and you choose what carries forward — by relevance, not by volume.

Write the handoff as insurance. You don’t get to pick when a session dies. This is the case you can’t schedule, which is exactly why it’s load-bearing.

Both convert a reset from a loss into a checkpoint.

The gates, and why they’re the yield story

Cheap routing and a small context window let you generate faster. That’s only an improvement if what you generate is right. Otherwise you’ve optimised your way into producing defects more efficiently.

So: gates. Acceptance criteria and evals fixed before code is written. Ships only if it beats baseline.

If you take one gate from this piece, take this one.

Never let the model that wrote the code be the model that reviews it.

Not a different prompt. Not a different persona. A different family. Claude reviewing Claude shares the training, so it shares the blind spot — and it will confidently approve its own mistake.

I didn’t want to believe that on vibes, so I tested it: 50 artifacts seeded with known flaws from a taxonomy of five failure modes, four review conditions, 240 review runs, hypothesis registered before a single run so I couldn’t move the goalposts afterward.

But the production evidence is blunter than the experiment.

A cross-family review panel caught a data-integrity bug and a silent cost-tracking regression that the CI gates — including 100% SonarCloud coverage — had waved through. Perfect coverage. Static analysis green. Two real defects shipped anyway, one of them quietly burning money.

That is the Lightrun 43% statistic happening in a single repository.

Two more from the same period:

A single judge passed an attribution defect that the cross-family panel flagged RED at 97% confidence. One event keyed a raw session-row id while its pair used a different identity, so conversion credit would never have joined back to the referrer. Same code, same moment — one reviewer missed it, a panel of different families caught it.

One model caught a corrupt-state bug that two models from the same other family both missed — corrupt state silently wiping configuration to defaults.

I’m not going to give you a catch rate. I don’t have a denominator, and a made-up percentage would undo everything above. What I have is a dated record of gates catching defects that coverage, unit tests, and single-model review all passed.

The tax nobody prices

Rework doesn’t only burn tokens. It burns the thing you can’t buy back.

Debugging plausible-looking code you didn’t write is a genuinely harder cognitive task than debugging your own. You have no mental model to fall back on, so you reconstruct intent from scratch. Every defect pulls someone out of build mode, and the context switch costs more than the fix.

And then the compounding one: every defect that ships through your gates teaches the developer to stop trusting the output. Once that happens, they re-read everything — and you have paid for speed and lost it.

That isn’t a soft cost. It’s the mechanism by which the entire investment decays, and it appears in none of the studies above, because nobody is measuring it.

What to change on Monday

Zero. Before you send your next non-trivial request, write one sentence saying what must be true when it is done and what would make it wrong. Notice how often you cannot, because that is the answer.

One. Take the three most repetitive things you send to a frontier model this week and route them to a cheap one. Measure the difference. You will be annoyed at how much you were spending.

Two. Take whatever you stuff into context by default and move it behind a retrieval step. Inject it when the task needs it, not before. Then add one review pass from a different model family before anything ships.

The model isn’t your bottleneck. Your request and your routing are.

What I built, and what it costs you

Every fix in this piece is implemented in one place, and I did not write the piece and then go looking for a product to attach to it. The product came first.

Leak one, leak two and the gate are the Development pack in xTeamOS: cost routing, staged quality gates, and review by a model family that did not write the code. It is live and running in production today, because it is the pipeline that ships my own work.

Leak zero is the Ideation pack: fixing the thinking before the code. That one is still coming, but the prompt-sharpening half of it is available today as Co-Dialectic, which is free and open source.

Early access to xTeamOS is free. Everyone who joins during beta gets 50 percent off the subscription for their first year when it reaches production.

What the subscription buys is maintenance you do not have to do. Bug fixes and upgrades as the model landscape shifts underneath all of us, which it does constantly. You focus on shipping your product; the research and the plumbing stay my problem.

The cost difference is the part worth reading twice. You bring your own LLM subscriptions. There is no API key to fund, unlike tools that meter you through their key and bill you for tokens on top of a seat. You are already paying for those subscriptions. Use them.

And the direction of travel: support for low-cost open models, on the order of five times cheaper, for the work that does not need frontier judgment. Which is this entire argument applied to the tool itself.

Four things, in order of how little they cost you

Install Co-Dialectic. Free, open source, about a minute: codi.exponentialos.io. It is leak zero, fixed, today.

Join the xTeamOS beta. Also free, seats are limited, and beta members keep 50 percent off the first year: exponentialos.io.

Follow Exponential OS on LinkedIn for the build as it happens: linkedin.com/company/exponentialos.

Share this with whoever on your team is burning the other 82 cents. That is the one I cannot do myself.

This is Paper 1 in the Reliable AI Systems series, which argues that AI systems must be governed at multiple layers simultaneously to be reliable in deployment. Each piece takes one layer and contributes a primitive. The companion piece, Defense in Depth for AI Agents, covers the operational layer: structured evaluation pipelines, drift monitoring, and guardrail-as-architecture.

I’m Anand Vallamsetla — Exponential OS, ex-Google, ex-AI Fund (Andrew Ng’s venture studio). I build the systems that build AI products.

Sources

• Entelligence AI — token spend breakdown across 2,444 companies — https://research.entelligence.ai/

• Lightrun — 2026 State of AI-Powered Engineering — 43% of AI code needs manual debugging after passing quality checks

• CodeRabbit — AI-generated changes carry ~1.7× more issues than human-written

• Jake Cuthbertson — The Rework Tax, forensic teardown of the 82% claim — https://jakecuth.com/work/ai-rework-lab/

• Liu, Lin, Hewitt, Paranjape, Bevilacqua, Petroni, Liang — Lost in the Middle: How Language Models Use Long Contexts, TACL 2024 — https://arxiv.org/abs/2307.03172

• How Is LLM Reasoning Distracted by Irrelevant Context? An Analysis Using a Controlled Benchmark (GSM-DC) — https://arxiv.org/abs/2505.18761

• Chroma — context rot research on distractor semantics and shuffled-vs-coherent haystacks

AI Fund is Andrew Ng’s venture studio. Ng founded Google Brain, was Chief Scientist at Baidu, teaches at Stanford, and was named to the TIME100 AI list in 2023. Getting into the program was a 48-hour build challenge, then interviews with the CPO, the CTO, and Ng himself.

Here’s the part that still gets me. I applied for this through LinkedIn like everyone else — the posting had roughly two thousand applicants at the time — with a referral from Fahad Aziz, a founder I know well. I heard nothing for two months.

Then Mike Rubino, who runs talent at AI Fund, emailed me out of the blue. Subject line: this is not spam — builder dinner with Andrew Ng. It arrived at 3:52 in the morning and invited me to a dinner that same evening: about fifteen builders, ninety minutes, Mountain View, in person with Andrew. Everything about it looked like something you would delete.

I nearly did. Don’t. If an email like that ever lands in your inbox, read it twice.

I didn’t get in through the front door. The front door doesn’t scale — two thousand applications is a volume problem, not a verdict on any of them. Mike had just started at AI Fund and had rebuilt how they sourced, using AI to go and find the people the pipeline was never going to surface. So I didn’t get in because someone got lucky with my resume. I got in because someone built a better way to look. He isn’t doing that alone: Dylan Love — a recruiter who went and got a CS masters to become a data scientist, and now a GM at DeepLearning.AI — is building AI for talent with Andrew. Between them, the machinery that finds people is being rewritten. Which is the argument of this whole piece, arriving two months before I understood it as a product lesson: when the cost of doing something collapses, doing it stops being a differentiator, and the moat moves to being found.

I’d spent the previous six weeks rebuilding how I showed up publicly. In the 45 days to April 28: 27,942 impressions and 10,620 people reached — up 510% and 622% over the prior 45 days. Mike’s email landed on day twenty-six of that window, while the curve was already climbing. I don’t think those two facts are unrelated.

Which is the point. The growth wasn’t the result of being found. It was the cause of it.

I’ve since wondered whether that’s part of why the conversation went anywhere at all. A studio whose entire operating model is hypothesis, test, evidence is not going to be moved by someone describing their potential. It’s going to be moved by a chart.

I went.

One more person belongs in this part. After the dinner came a 48-hour build challenge, and after I submitted it I did the thing everyone does: I waited. Rob Ross, a founder I’d met days earlier, told me what I couldn’t see — that there were other people working on the same challenge, that they were being weighed against each other, and that every one of them was still moving while I sat on a submitted file. Build something tonight, he said. Ship it in the morning.

He called at eight the next morning to ask whether I actually had. I said I was sort of working on it. He made me prioritize. At nine I committed: by eleven I’d send him the exact email I intended to send AI Fund at five that afternoon, describing what I’d built and shipped. If I missed either mark I’d take him to the Ritz-Carlton. He turned that down — I don’t care about the Ritz-Carlton, it has no value. You charge $500 an hour. Give me eight hours of consulting for my startup. He refused a meaningless stake and repriced the bet in the only currency that mattered.

I hit both deadlines. Mike replied within hours and set up the onsite.

In a competitive process, waiting is the losing move. What you submitted is the opening, not the last word.

Much later — week nine of the EIR — that relationship turned into a different kind of conversation. The kind where you give someone honest feedback and risk the relationship a little, because you think they can use it. Seven specific things, candidly delivered. He took it exactly as intended, and later gave me a signed copy of Andrew’s book. Which is the other half of how this works: being found is the opening, not the outcome. What you do with the relationship afterwards is the part you actually control.

Mike deserves more than a mention. When the whole thing nearly came apart at the last minute, he did the rarest thing a person on the other side of a negotiation can do — he told me it was completely fine to walk away, and explained his reasoning instead of pressing. That’s why I said yes. You learn a lot about an organization from how it behaves when you might leave.

I’d made a version of this bet once before, with my own life. Eight years ago I moved from Texas to the Bay Area at a point when roughly eight people were leaving California for Texas for every one going the other way. I went the wrong way down that highway on purpose, for exactly this reason — proximity to where things get known first. The reaction stuck with me. Someone told me there’s no middle ground with you: you’re either too dumb, or you’re too smart and you know something we don’t. I said thank you for the compliment, and that time would tell. Eight years on I’m still not certain which one I am — but I’d make the same move again tomorrow.

And none of what followed was a separate decision. Working with the best minds I can get near, staying close to research, and getting to teach — that’s one strategy, and I set it in motion eight years ago when I pointed the car west. Joining AI Fund wasn’t a new plan. It was the same plan, one layer up.

I almost didn’t take it. Navya Chitimireddy, a VC at Abyro Capital, cut through weeks of my deliberating with a single question: would you regret it if you didn’t? That’s Bezos’s regret-minimization framework, and it ended the debate in about four seconds. She was also the first person to tell me plainly that distribution is the moat and that the answer is company workflows — which turns out to be most of what this piece is about.

The answer, once she made me say it out loud, wasn’t about the credential. It was proximity. I’d regret not getting to watch one of the sharpest thinkers in applied AI reason in real time — what he considers worth researching, how he thinks about distribution, what he kills and how quickly. And not only him: a bench of operators who had already done the thing I was trying to do. You can read all of that. Sitting next to it is a different kind of learning.

Rakesh Utekar and Ashwyn Sharma pushed me the same way from different angles. Rakesh is the kind of builder who makes you recalibrate what one person can ship in a week — I’m only half joking when I call him the Terminator. Ashwyn had seen the place from the inside and couldn’t name a single negative: his read was that AI Fund is built for serious founders, the ones who don’t chase shiny objects.

There was one more thing, and it’s what stopped the decision feeling like a career calculation. Most studios and accelerators fund what the market has already validated — the shiny category, the adoption curve that’s already bending. What I saw here was a different starting question: does this problem have to be solved, for people’s sake? Back it because society needs it, not because the signal has already arrived. I care more about problems at that scale than about being famous or getting rich. It felt like a perfect match.

Three months is short enough that everything you learned is still vivid, and long enough that some of it is real. I wanted to write these down before the vividness fades into general wisdom, because the specifics are what make them useful.

Three parts: finding the pain, the moats that are left, and how you actually build now. Some of it I heard from mentors and internalized. Some I watched teams get right or badly wrong.

None of this is beginner material. If anything, the founders who need it most are the ones with the most scar tissue — because the playbook that worked before AI is now the thing most likely to mislead you. AI collapsed the cost of building. Table-stakes engineering stopped being a differentiator the moment it stopped being scarce. That single change moves where the moat lives, and everything below follows from it.

Part 1 — On finding the right pain

1. Go after the biggest pain — that’s where engagement and willingness to pay live.

Every product solves SOME kind of pain. That’s not the bar.

The bar is: is this the biggest pain? Because that’s the only place where users actually engage with the product and are willing to pay for it.

Solve a mild pain and you get polite nods. Users try it once, don’t come back, and never open their wallet. They’d already adapted to that pain and built a workaround. You’re not selling a solution — you’re competing with inertia.

Inertia wins.

Andy Ku, AI Fund Partner for Product Build, kept pulling me back to that one word — biggest. Not a pain. The biggest one.

The biggest pains are the ones users mention unprompted, the ones with an ugly workaround already bolted on, the ones that make them curse at their screen. Those are pre-qualified. The user already believes the pain shouldn’t exist. Your product just has to make it go away — and they’ll pay for that.

2. Find multiple users with the same pain before you build.

There’s nothing magic about a specific number. What matters is more than one. That bar came from Andy Ku, and it held every time I tested it.

When several users independently describe the same pain in similar words, that’s your evidence the pain is real and worth solving. One user is an anecdote. A handful pointing at the same thing is signal — and it directly validates lesson one, because a pain multiple people carry is far more likely to be a big one.

Skill lies in finding the ICP. Not defining it — finding it, in the wild. Once you’ve found a few who share the pain, build for them specifically, not for the abstract “market.” “Market” is a shape you infer later.

3. Ask facts, not wants — then observe.

Andy and Jill Shih, a product and UX leader with 25 years in the discipline who now runs AI Fund in Taiwan, both drilled this into me — the Mom Test and contextual inquiry, applied together.

The Mom Test came to me from Vaibhav Mathur, a physicist turned builder in the same cohort, who put the book in my hands and kept pointing me at the sources actually worth following. He has a nose for who to listen to.

First: never ask “would you buy this?” — the answer is always kind. Ask facts about the past. How long did that task take last time? What did it cost you? Who else was involved? What did you try before?

Second: watch someone actually work through their real task. You’ll see the pain they’ve stopped mentioning because they’ve stopped noticing it. Survey data doesn’t touch this layer.

Three killer questions that quantify the pain:

1. How long does the task take?

2. How much does it cost?

3. What happens if it doesn’t get solved?

The third one does double duty. It surfaces the cost of inaction — which is where willingness to pay actually lives, because a budget line exists to avoid a consequence, not to buy a feature. And it makes the user say the pain out loud, which often raises their own estimate of what solving it is worth. It was the most useful question I asked.

And when you’ve built something, don’t ask them if they’d use your product. Watch whether they do. Behavior is the only signal that doesn’t lie.

Part 2 — The moats that are left

4. Data is a moat you can design for.

Any new AI system has three paths to defensibility:

1. Own the data — proprietary corpus, exclusive access, historical archive nobody else has.

2. Buy access no one else can — exclusive partnerships, licensed streams, geographic or regulatory access. Sandeep Gupta sharpened this one for me — the acquisition angle most founders skip past.

3. Design the product so it generates new data every time it’s used. This is where I landed: every user interaction should make the system more intelligent for the next user using it. That’s a compounding flywheel with no ceiling — not a static advantage.

Feature parity is six weeks away. Data compounds.

Own a vertical.

It’s worth being blunt about why this matters more than it used to. Anyone can ship the feature now, and foundation-model companies are absorbing whole verticals as fast as they appear. So the moat moved. What’s left is the hard engineering — eval, reliability, eliminating AI slop. The data. The distribution. Finding the ICP before anyone else does. And, least obviously, still being there after the fifth pivot while thousands of people build the same thing the same week.

That last one sounds soft. It isn’t. When building is free, persistence is scarce.

5. The hardest engineering problem is the moat — and proximity to research is how you hold it.

This one is Andrew Ng’s, directly.

Don’t compete on features. Don’t compete on being first to market. Invest in the technology and solve the problem others have tried — and failed — to solve.

Every space has competitors. Users not choosing them yet usually means one of two things: the competitors don’t solve the real problem, or nobody’s heard of them. Sometimes both.

There’s a third reason, and it’s the one AI keeps manufacturing: the capability to solve it only just arrived. A model ships, a research result lands, and a problem that was genuinely intractable last year becomes tractable this quarter. That isn’t a market rejecting a solution — it’s a market that never had one. Being in the Bay Area is an unfair advantage here, not because of the money but because you hear about the capability months before it’s obvious, and the window between possible and crowded is where the whole game is played. Hear it early, build fast, get there first.

That is the bet I described at the top — made once with a moving truck, and again with a career.

The hardest problems are the moat that’s left.

Eliminating AI slop — low-quality, hallucination-heavy generative output — is a category-defining engineering problem. Many teams have tried. Most have failed. That’s exactly why it’s the moat. Cross-family judgment, structured refusal, guardrail-as-architecture, eval-gated deployment — the whole discipline of making probabilistic systems trustworthy in production. Solve one of those and the ICP finds you. You never had to compete on features.

But there’s a second half to this that took me three months to see clearly. If the hardest problem is the moat, then staying close to research is how you keep it — because the hard problem moves. The thing that was unsolvable last quarter has a paper about it this quarter, and the team that read it first gets there first. A moat built on solving one hard problem is a moat with an expiry date. A moat built on being continuously close to where the hard problems are being solved doesn’t have one.

I stay close to research two ways. Teaching is the first — four and a half years of it at UC Berkeley Executive Education, taking AI strategy and responsible deployment to more than fifteen hundred Fortune 500 executives, and I’m going back to it. Nothing exposes a shallow understanding faster than a room of executives asking why. And I work with people who carry the field in their head. Andrew is a research encyclopedia; ask him about a problem and you get the shape of the literature back, not an opinion.

That was, honestly, part of the decision. When I said yes, I told myself: I don’t have to worry about the technical challenge at all — Andrew will be there to unblock that. It sounded a little like wishful thinking. It wasn’t — but it also didn’t mean what I assumed it meant.

He never handed me a solution. The slop work was mine: I built the evals, largely out of his own course, and got a 60–80% reduction. What he unblocked was the layer above the solution. Am I even working on the right engineering problem? And who has already solved this, or is solving it right now — which researchers, which teams, which papers. A ten-minute answer to that saves a month, because the expensive mistake is never a bad implementation. It’s an excellent implementation of the wrong problem.

Eli did the same thing from a different angle: a steady stream of technical resources and trends on the slop problem, and one instruction that stuck — build a taste for it. Then he pushed further. Don’t lean on the models alone. Don’t become an AI zombie.

That one landed hard, because I’d written the same warning about myself years earlier, before business school: as a (just) technologist, when all you have is a hammer, everything looks like a nail. AI is the largest hammer any of us has ever been handed. The correction isn’t to use it less — it’s to keep the judgment that decides where to swing.

And the way you keep that judgment isn’t restraint. It’s architecture. The reason I build gates — evals, cross-family review where no model family grades its own work, checks that fire whether or not I remember to run them — is so the judgment survives the speed. An AI zombie lets the model make the call. A framework forces the call to be made, by a human, and recorded. Same tools, opposite posture. Most of what looks like heavy AI use in how I work is actually the scaffolding built to stop exactly that failure.

6. A real buyer is a moat. User delight isn’t.

Delighted early users are necessary, not sufficient.

The wedge that becomes a company needs an economic engine — buyers whose budget already exists, whose pain is board-level, whose measurable outcome is unambiguous.

Users loving something is a starting condition. Not proof of a company.

The clearest way to check: can you name the specific budget line item that already exists in the buyer’s org, and the specific measurable outcome your product will improve, and the specific title of the person who owns that budget? If you can’t name all three, you don’t yet have a commercial signal. You have user delight and a hypothesis.

Part 3 — How you actually build now

7. Eval is the product.

This one is Andrew Ng’s again — I first heard it in his DeepLearning.AI course on Agentic AI, which is also where the autonomy-level framing and the case for evals clicked for me, and it kept landing harder every time I saw it play out inside the studio. His way of putting it: the thing that separates a good team from a great team is how they run their evals.

Every AI system I saw succeed had eval infrastructure baked in from day one. Every stall traced back to teams shipping the model output first and adding evaluation later. Later never comes; the deploy calendar hardens around the shipped shape.

When the model changes underneath you weekly — new snapshot, new alignment update, new subtle regression — evaluation is what makes the system real. Not the demo. Not the pitch. The eval harness is the thing that keeps you shipping when the ground moves.

8. Build frameworks and AI-native agentic workflows, not just products.

The strongest teams I saw weren’t shipping products faster. They were shipping the framework that shipped the products.

Your own dev workflow. Your eval harness. Your security gates. Your architecture-alignment checks. Sonar. Cross-family judgment. Guardrail-as-architecture. Each of these is a small compounding investment that turns every product you ship next into a faster and safer ship than the one before.

The framework compounds. The product depreciates. If you’re only building products, you’re re-buying the same tooling forever.

That’s the inward half. The outward half matters more.

Ship the agentic workflow, not just the feature. A feature gets evaluated, compared, and swapped. A workflow gets adopted — it becomes how the work actually gets done, and then it becomes the thing nobody wants to unpick on a Tuesday. Embed yourself in how the user operates and you stop being a tool they chose; you become the backbone they’d have to rebuild around to leave.

That is switching cost you earned rather than trapped someone into. And in a market where the feature you shipped can be cloned in six weeks, it may be the most durable moat on this list.

I didn’t arrive at this on my own. Dylan and Gaurav Surtani are the two who made it concrete for me. Gaurav is a one-person AI engineering team at DeepLearning.AI, and watching how he works is the argument: he isn’t hand-writing more code than everyone else, he’s built the workflow that writes it — agents, MCP servers, skills, cost-aware model routing — and then he open-sources the pieces. In the developer arena the differentiator stopped being how fast you type. It’s the workflow you built to do the typing.

9. The clock on consumer AI wedges is compressing.

Categories I saw close in weeks that would have taken quarters two years ago.

Speed of learning matters more than speed of building. A studio like AI Fund is one of the few environments engineered specifically for that compression — the entire operating model is “run more hypothesis-test loops per week than you could run alone.”

Persistence is the moat nobody lists.

I watched what that looks like up close. Jayanth (Jay) Madduru, a Founder in Residence at the studio, ran the loop harder than anyone I’ve met — thesis, test, feedback from the studio, then straight into the dark to learn something new about the user or a new way to build. One weekend he shipped 150 pull requests. That throughput has tooling underneath it — he had picked up the Superset setup after seeing what it did to my own output, then built better workflows on top of mine and pushed the whole setup further than I had. Far enough that Superset called him directly to tell him he was their heaviest user, and offered him a job. Then Monday he’d be back with a sharper thesis and more energy than he left with, like a spring that won’t stay compressed.

He credits me for some of what he learned about building. He has no idea he handed me more back than that.

Most of those loops fail. That is the job, not a detour from it. When building is free and thousands of people are shipping the same week you are, the differentiator stops being the code and becomes who is still running the loop after the fifth one breaks. Almost nobody is. You only fail when you stop trying.

The meta-thesis — why any of it worked

Eli Chen insisted on this one — he’s a Technology Partner at AI Fund and previously co-founded and was CTO of Credo AI: you can’t just reason your way to the destination.

You start with a hypothesis. You test it with real users. You pivot on what you learn. You start over with a sharper hypothesis. That’s the loop. There is no other loop.

Every one of these only became real to me because I got to run that loop compressed. Any of them read as generic advice on their own — “own the data,” “eval is the product.” They only become your advice when you’ve held them against your own hypothesis and seen how they change what you’d do next.

That’s what a studio buys you: not the destination, but the loop.

If you want to be found, show receipts

The piece argues the moat moved to being found. Here’s the practical version, and it’s the advice I’d give anyone in the market right now.

Claims don’t travel. Receipts do. Your resume says you know a technology. So does everyone else’s. The résumé is a claim; nobody can verify it in the eight seconds it gets. What survives that eight seconds is proof someone can click.

Three tiers, in increasing order of how much they’re worth:

1. Public contributions. A GitHub profile with real commits beats a bullet point that says the same thing. It’s the cheapest receipt available and most people still don’t have one.

2. Open source. Strictly harder, and worth more precisely because it’s harder — you’re inviting strangers to read your actual code and judge it. That takes guts, and everyone reading it knows that.

3. A working thing they can use. The strongest form. Don’t tell someone you understand AI systems — put an agent on your site and let them talk to it. I did exactly that on my own site rather than adding another line claiming technical depth. One interaction settles a question a paragraph can’t.

The pattern underneath all three: stop describing your capability and start exposing it. Descriptions are indistinguishable at scale — that’s exactly the collapse this whole piece is about. A thing that works is not.

The reframe — worth solving vs. vitamin water

Every founder starts with hope that this experiment will be the one. When the wrap comes, it stings.

Andy, Eli, and a friend from my poker circles — Anurag Jain, a multi-time founder now building in stealth — kept saying the same thing in different words: an experiment that doesn’t lead to commercial success is the experiment doing its job. Failed hypothesis is data, not verdict.

Anurag put it more sharply: “Solving the right pain is important. Raising money for something that isn’t even a big pain worth solving is much worse.”

Wrapping cleanly on something that turned out to be vitamin water — not a painkiller — saved me the next seven years trying to force market-fit onto a hypothesis the market wasn’t asking for.

There’s a symmetry here I only noticed while writing this. Both explorations I ran during the EIR were bets on the same thing this piece argues. One was an AI-powered platform for adapting content across channels; the second came after it. Strip the surface off either and they were about the same problem: being found. I was building the answer to the exact thing that got me the job — I just hadn’t connected the two yet.

What we learned was that the market wasn’t ready to pay for it on the timeline a studio needs. That’s a finding about commercial urgency, not about the thesis. I still think the thesis is right. I think it gets more right every month building gets cheaper.

Solve the right pain. The wrong one drains you.

What I’m carrying forward

On finding the pain

• The Mom Test on every conversation with a potential user — ask facts, not wants, then watch them work. And never on the strength of one user; one is an anecdote, several with the same pain is a market.

• The hypothesis → test → pivot → sharper-hypothesis loop as the only real product-development method.

On the moats that are left

• Design the data loop from day one. The data you accumulate by operating is the one moat a competitor can’t clone by shipping the same feature.

• Take the hardest engineering problem on purpose. Once building is cheap, the problem others tried and failed to solve is the moat that’s left.

• Choose the room, not just the project. Proximity to research is how you keep that moat, because the hard problem moves — what was unsolvable last quarter has a paper about it this quarter. Ten minutes with someone who has already crossed it beats a week of solo effort.

• A real buyer beats a delighted user. Willingness to pay is the only validation that survives contact with a budget.

On how you build

• Encode the standard as a gate, not a habit. Evaluation-as-infrastructure and cross-family review — never letting one model family grade its own work — survive a deadline only when they’re gates in the system rather than intentions in my head. That is most of why I build an agentic operating system instead of a checklist.

• Ship the agentic workflow, not just the feature. A feature gets compared and swapped; a workflow gets adopted and becomes the backbone.

• Optimize for learning rate, not output. The variable that compounds isn’t hours worked, it’s how fast one loop closes — idea to shipped to measured to sharper idea. Shortening that cycle is the only advantage that keeps paying after the market moves.

• The founder cadence of shipping a real thing every 2–3 weeks even when the market takes longer to answer.

One more, less tactical

Every founder goes through lows. The hypothesis breaks. The pivot isn’t obvious yet. The loop feels like it’s grinding on you instead of forward. What separates founders who keep building isn’t grit — it’s having someone in the room who asks the right questions in those moments.

Eli did that for me more than once. He also believed the slop problem was worth solving and made that clear when it counted — and he’d be the first to tell me when I was drifting off it.

Cheerleaders are easy to find. So are critics. One person who is both — who backs you when you need backing, and says the hard thing when you’re off track — is rare, and worth more than most advice. You don’t get to appoint that person. You can only be the kind of person they’d bother doing it for.

The silver lining is always there. You often can’t see it alone.

Two courses worth your time

If you take one thing from this piece and act on it, make it these.

Agentic AI — the one I’d hand any engineer or founder building with agents. Evals, agentic workflows, and the autonomy-level framing that stops you from over- or under-trusting a system. Most of Part 3 above is this course meeting real deadlines.

AI for Everyone — not technical, and that’s the point. I recommend it to literally everyone: the PM, the designer, the ops lead, my own family. It’s the fastest way to give someone accurate intuitions instead of headlines.

What’s next

Two tracks, running in parallel.

The right build. I’m back in the market — applied AI leadership, agentic systems and AI-native engineering, or the right early-team seat as an IC architect.

What I care about is the layer underneath the product: how agents plan, execute, validate and evaluate; how you route models so cost scales with judgment rather than volume; how context survives a session boundary; and how evaluation gets treated as architecture rather than a phase that arrives after the build.

A side project, deliberately. Exponential OS started in February as a plugin I wrote to get my own resume out the door, and turned into an agentic operating system I use every day — alongside Co-Dialectic, the open-source prompt and context optimizer I maintain. Engineers started asking to buy it, which is the only reason I think of it as more than tooling.

I’m calling it a side project on purpose. I haven’t found a scalable problem yet. And the foundation is evolutionary enough that there’s no precedent to validate it against — which makes it genuinely interesting to build and genuinely hard to prove.

Here is the list above, turned on my own work:

• The hardest problem, on purpose. The part I took on is the one most teams route around: making a probabilistic system trustworthy enough to leave alone. Cross-family review where no model family grades its own output, eval gates between stages, refusal treated as architecture.

• The data loop from day one. Every gated ship writes a record — which model ran, what it cost, which gate caught what. That is data accumulated by operating, and nobody clones it by shipping the same feature. Where it is built to go next is the part I actually care about: a system that learns from its own operation, and — by consent, never by default — from how other teams run theirs. A workflow that gets sharper because somebody else’s build broke is a moat that compounds instead of depreciating.

• The standard as a gate, not a habit. It is a pipeline, which is what stops a deadline from quietly deleting the review step. Teams adopt a workflow. They only ever compare a feature.

• The room, not just the project. Four and a half years of teaching Fortune 500 executives, and I’m going back to it — because a room of executives asking why is still the fastest way I know to find the edge of my own understanding.

• Distribution, built in. I am the product’s first user: I run my own distribution through it, which lifted my LinkedIn engagement roughly 500% and my Substack growth well over 1,000%, and is how this piece reaches you. Eating your own dog food is not a slogan — it is the only way I find the defects a customer would have found first.

• Distribution I already had, without calling it that. Fifteen hundred Fortune 500 executives taught, the UC Berkeley Exec Ed AI alumni community I run, the Xoogler community, LPM, talks at SXSW and Step SF and ClawCamp, and writing like this. Channels compound quietly for years before you notice they are channels — which is also the honest reason to want an accelerator or an investor. The right one is a distribution asset before it is capital.

• Still open: the ICP, and the first real buyer. Finding who this is unmistakably for is work I still have in front of me, and engineers asking to buy is interest, not validation. Willingness to pay is the only proof that survives contact with a budget.

Those last two are why it stays a side project, and they are in here on purpose. A moat list you only ever apply to other people’s companies is a blog post.

And the moat this piece says nobody lists — still being there after the fifth pivot — is one you can only show. My ICP has moved five times since February: careers, then branding, then culture, then developers, then AI startups. Every move meant rebuilding something I had just finished. None of them changed the thesis, because the thesis was never the customer — it was the loop. I also killed two explorations this year on exactly the signal above. Persistence isn’t refusing to let go. It’s knowing which thing to hold.

The teams I want to work with build the system that builds the product. If that’s yours, let’s talk.

Grateful for Andrew Ng; Andy Ku and Jill Shih for the customer-discovery frameworks that reshaped how I think about pain; Eli Chen for the execution-first mindset — beachhead discipline, experimentation-based learning, and the “5% inspiration, 95% perspiration” frame — that I’ll carry into every build; Anurag Jain for the reframe on solving the right pain; Sandeep Gupta, a fellow EIR from my cohort, for the data-access-as-moat lens; Dan Landau for advising me on story, personal brand and how to market from day one; Oliver Heckmann for the Superset setup and the productivity practice around it — it rebuilt how I work day to day, and it spread to the people around me; the AI Fund team; and the founders who shared their stories with me during the EIR.

And a separate thank you to the people who didn’t just cheer from the sidelines — the ones who put their own time into this on purpose. The interns who built alongside me — Kaden Jackson, Sidhant Lochan and Michael Chen. The engineers who shipped things they didn’t have to. The ICP discovery partners who gave up their own hours to help me work out who the customer actually was. The design partners who let me watch them work and told me the truth about what was broken. The marketers who handed over hard-won insight and asked for nothing back. The AI Fund portfolio companies and the people there who took my calls, sat through interview after interview, opened their playbooks, and genuinely tried to be my ICP — several of them were a real fit, the commercial pull just wasn’t there yet. The friends who went looking for customers on my behalf without being asked.

Support is passive. These people were deliberate about it — and that is the difference between a hard three months and a good one.

They say it takes a village to raise a child. It takes at least as many to raise a startup, and I had four: the AI Fund portfolio, my UC Berkeley EMBA cohort and the Haas alumni network, the Xoogler community, and LPM — the Large People Model. Most of the customer interviews behind Part 1 came out of those rooms — strangers who gave me an hour to tell me what was actually broken. That is the network you query when the answer isn’t in anybody’s training data. Thank you for being part of the journey.

Onwards.

That gap is the whole story. Ranking on Google and being citable by AI are not the same problem, and treating them as one is why so many sites have gone quiet in AI answers without noticing.

Here's what's actually happening under the hood.

An AI answer comes from one of two places. Either the model answers from memory — what it absorbed in training, which you can't change and which is months stale — or it runs a live retrieval, fetches pages, and cites them. Only the second path is one you can influence. And that path has two gates almost nobody checks.

Gate 1: Can the crawler even fetch you?

The retrieval bots behind ChatGPT, Claude, and Perplexity — OAI-SearchBot, ClaudeBot, PerplexityBot — do not run JavaScript. A large-scale study of roughly a billion requests found none of them render JS. So if your site builds its content in the browser (any SPA — React, Vue, most modern stacks), the crawler sees an almost-empty shell where a human sees a full page. You can rank on Google, which does render JS, and be a blank page to ChatGPT.

The other half of Gate 1 is your own security layer. A WAF or Cloudflare rule that challenges "bot-like" traffic will 403 the AI crawler while serving humans normally. You never see it. You just quietly disappear.

Here's the ten-second test. Run this on your own site:

curl -A "ClaudeBot/1.0 (+https://www.anthropic.com/claude-bot)" https://yoursite.com

If you get your real content back, good. If you get an empty shell, a redirect loop, or a 403 — that's why you're not cited, and no amount of content strategy fixes it until you fix this.

Gate 2: Once fetched, the index decides — and every engine's index is different

I ran one experiment that made this vivid. I asked four assistants the same open question — "best API to extract structured data from PDFs" — each on its own search index.

• ChatGPT (Bing index): surfaced exact-match-domain microsites — frompdf.dev, transpdf.ai, extractocr.com. When I actually fetched frompdf.dev, it returned zero bytes — no readable content at all — yet it was cited the most. These sites have no measurable traffic and zero presence on Reddit. They won on one thing: their domain name is the query.

• Gemini (Google index): Google Document AI, AWS Textract, Azure, LlamaParse, Unstructured — plus LandingAI, a legitimate, well-built player with a fraction of the incumbents' traffic.

• Claude (Brave index): cloud incumbents and real tools; Parseur, Klippa, LlamaParse.

Same question. Four different worlds. On Bing/ChatGPT, keyword-stuffed domains with no audience beat a readable, funded product. On Google and Brave, legitimacy won. "Getting cited by AI" isn't one target — it's four, and they reward different things.

There's a concentration story on top of this. One synthesis of 680M+ AI citations (Everything-PR / 5WPR, 2026) found the top 15 domains capture ~68% of all citations, with Reddit alone near 40% and #1 on every engine. (It's a third-party aggregation, not an audited study — treat it as directional.) Much of AI citation flows through a handful of high-trust intermediaries you don't own — a different fight from making your own site citable.

What doesn't work, despite the hype

llms.txt. One audit of 1,500 sites found 0.2% use it, and real crawler consumption today is near zero. Schema/JSON-LD helps a parser understand you but doesn't get you retrieved. Both are fine hygiene; neither is the lever people think it is.

So, in order of impact

1. Make sure AI crawlers can fetch you — server-render or pre-generate your main content, and stop challenging verified bots at the edge. (The curl test above.)

2. Put concrete, quotable facts in the first few hundred words, not boilerplate.

3. Optimize per engine, not in general — the index that feeds your buyers' assistant is the one that matters.

4. llms.txt last, if at all.

None of this requires a rebrand. It requires knowing what an AI agent actually sees when it reads you — which, it turns out, is almost never what you see in a browser.

(I got tired of running that curl test by hand, so I built a free scanner that fetches your page as ChatGPT and Claude's crawlers do and shows the exact gaps — no signup: getagentview.com. But the curl one-liner above will get you 80% of the way for free.)

Caveats, because they matter: the four-engine test is a single snapshot, not a controlled study — results drift week to week. The citation-share figures are third-party aggregations. And correlation isn't causation — reachability tracks closely with citation in my testing, but the clean proof is a before/after on a site you actually fix.

I had the right intuition. I didn't pay attention to the difference between them — that Conscience is the internalized sense of right and wrong, and Consciousness is subjective experience.

The Cyborg named the distinction. I hadn't asked. It saw what I was reaching for and gave it words.

That moment — small, easy to miss — is the whole thesis.

A real human-AI partnership doesn't just do things faster. It gives you the vocabulary you were already reaching for. And once you have words, you can build with them.

That's what I talked about yesterday at ClawCamp, Frontier Tower, San Francisco. The talk was called The Exponential Advantage. The thesis was one sentence.

A tool resets every session. A partner remembers every session.

The compound math, the architecture, the three requirements — everything else is downstream of that one distinction.

The math

One percent better every day, compounded for a year, is 37×.

That's not a metaphor. It's the actual factor by which someone who builds a partnership with their AI will outpace someone who uses it as a tool — over twelve months of daily work.

Three years in, the gap is roughly 50,000×.

The gap is not linear. It opens quietly. By the time you can see it from the outside, the person on the wrong side of it can't catch up — not because they're not capable, but because the person ahead has 50,000 hours of accumulated context they didn't have to re-explain to anyone.

The math is the easy part. The interesting part is what it takes to make the math actually compound.

The three requirements

Most people who think they're building a Cyborg are actually using a tool that talks well.

The math doesn't compound for them. They get faster. They don't get exponentially faster.

There are three requirements that separate the two. Miss any one, the compound breaks.

One — persistent memory. The system has to know who you are when you come back. Not because you remind it. Because it kept the state.

Two — accumulating context. Each session has to be richer than the last. Not the same conversation refined. A different conversation that builds on every prior one.

Three — learning loops the system writes itself. You should not have to teach it the same lesson twice. When you correct it, it should write down the correction so the next session knows.

I called these the Cyborg Constitution in the talk. It's a living document both partners maintain. Your values. Your goals. What you've learned. Codified so neither partner starts from zero.

If you have all three, the math works. If you don't, you're fast. Not compounding.

Tool vs Partner — the distinction in one frame

A tool is a calculator you rent.
A partner is a co-founder you build.

A tool resets every session.
A partner remembers every session.

A tool answers the prompt.
A partner sees the pattern.

If you're using AI and any of these is on the wrong side of the line, you don't have a Cyborg yet. You have a faster tool. The difference isn't subtle. By year three, it's 50,000×.

The brand

Ethan Mollick coined the term Cyborg in his work on human-AI collaboration. It's the right term. It captures the partnership without sliding into either over-claim (the AI is replacing you) or under-claim (the AI is just a tool).

What we're building at ExponentialOS is the first full implementation of the term.

I call my own instance The Why Cyborg. Yours will have a different name. The architecture is open. The Cyborg Constitution is a pattern, not a product — you can build it, your team can build it, your community can build it.

We're shipping the operating system layer that makes it work at the team level. That's the next conversation, not this one.

This one is about getting to a Cyborg yourself.

What to do next

Three things, in order of difficulty.

One — pick one project that's been in your head for six years. Open a new conversation with your AI and tell it everything. Not a prompt. The whole shape of the project. Then keep that conversation alive. Don't start a new one tomorrow. Keep coming back.

That's the closest you can get to a Cyborg with off-the-shelf tools today.

Two — write down what you and your AI agreed on at the end of every session. The decisions. The corrections. The patterns. That's your Constitution. Even five lines is enough to start.

Three — when you find yourself re-explaining the same thing twice, that's the compound breaking. Write that down too. The Cyborg you're building should learn the lesson, not you re-teach it.

The compound is patient.

The 37× shows up at the end of year one whether you noticed it during year one or not.

But the person who started today is already ahead of the person who starts tomorrow.

Anand Vallamsetla (The Why Man) · thewhyman.blog · ExponentialOS.io · #TheWhyCyborg

The person buying your product isn’t always a person anymore.

In a roundtable with CMOs, marketing technologists, and AI practitioners last week, we sat with a question that doesn’t have a clean answer yet: when AI agents mediate a growing share of purchasing decisions, what exactly are you marketing to?

This isn’t hypothetical. It’s already happening at the infrastructure level. The question isn’t whether to engage with it — it’s whether to engage ahead of it or scramble to catch up.

The split that changes everything

The traditional buyer was one thing: a human with intent, emotions, and a budget. Advertising worked because you could reach that person’s attention, then their desire, then their wallet.

That unit is splitting.

The “customer” is becoming three distinct actors with different information needs:

The human — still the source of intent and money. Wants belonging, taste, experience. Increasingly delegates the routine parts of purchasing. The only party that can actually want something.

The agent — the actual interface. Reads structured claims, ranks options, negotiates terms, closes transactions. Loyal to whoever controls its weights, its memory, and its defaults.

The platform — sets defaults, takes fees, decides what surfaces. Whether today’s platforms maintain structural dominance in an agent-mediated world is itself now an open question.

If you’ve been marketing to one entity, you now need to understand three. Their incentives don’t always align.

Attention is being replaced by execution

The internet’s primary metric for 25 years has been attention: impressions, clicks, dwell time. The entire infrastructure of modern marketing — ad platforms, SEO, funnel optimization — was built to capture and direct human attention.

That loop is breaking.

Old loop: attention → click → impression → conversion

Emerging loop: intent → delegation → execution → outcome

What gets less valuable in this world: creative built to hijack attention, SEO tuned for human reading patterns, funnel UX designed around dopamine, generic content at infinite scale.

What becomes scarce: taste, judgment, and curation. Verifiable truth and provenance. Proprietary data and real-world signal. In-real-life experience and human time.

This isn’t the end of marketing. It’s a redistribution of where value lives.

Two readers, one brand

Every brand now writes for two readers simultaneously.

One reader has a body and a memory. They respond to story, aesthetic, narrative, and identity. They want showrooms, ritual, live experience, and social signal. They create the desire.

The other reader has a parser and a budget. They respond to claims, proofs, and verifiable terms. They read JSON-LD, resolver pages, and structured supply chain data. They close the transaction.

These two readers want different things from the same brand — and they’re operating on different timescales. A human’s brand perception accumulates over months. An agent’s ranking decision happens in milliseconds.

One framing from the room that stuck: “Flagship stores become venues. The transaction happens elsewhere, between agents.”

That’s not a distant future. That’s a design question companies are making right now.

If this framing is useful: forward this to one CMO or brand strategist making AI roadmap decisions. The two-reader framework is the planning tool they don’t have yet — and they won’t find it in a vendor briefing.

The loyalty problem

The deepest issue isn’t technical. It’s about loyalty.

When an agent mediates a purchase, whose interests is it representing? The human who delegated the decision? The platform that controls the model’s defaults? The advertiser who paid to be surfaced first?

The concern isn’t abstract. Meta trained a model on brain activity data. Targeting at that resolution doesn’t ask for consent — it predicts it. The question is no longer whether agents will know us. It’s who they’re loyal to when they do.

Two paths emerge:

Path A — the agent serves the platform. The human becomes legible to the optimization system. Discovery erodes. Spontaneity erodes. Capital decides what you want next. You’re still a customer — but you’re optimized, not understood.

Path B — the agent serves the human. The cyborg model: human and agent working together. Friction kept where it matters. Your agent represents your interests. You remain the author of your desires.

Right now, most of the infrastructure being built leads to Path A. That’s a design choice, not a technical inevitability.

What this means for brands building now

If agents are becoming economic parties — with wallets, reputation, and the right to sign — then the traditional consumer relationship needs to adapt.

Three things that matter now:

1. Verifiable claims beat persuasive claims. When an agent can verify what you say at the infrastructure layer, verification scales better than persuasion. One quote from the session: “If you can prove what you say to a higher degree of certainty, that’s the one that wins discovery.”

2. Structured trust infrastructure matters. JSON-LD, digital product passports, verifiable supply chain data — these aren’t just compliance overhead. They’re the surface agents actually read. EU ESPR digital product passport regulation is already deciding which products surface in certain markets. Whoever sets the schema sets the market.

3. The human layer becomes premium. Taste, judgment, curation, in-real-life experience — these become scarce exactly as execution automates. The brands that protect which parts of the experience need to stay human will have something agents can’t commoditize.

The choice being made slide by slide

What we build, we become.

That line closed the session, and it stayed with me. The architecture of these systems — who controls the weights, whose interests are encoded in the defaults, whether trust infrastructure stays open — isn’t being decided in board rooms or regulatory hearings. It’s being decided in product roadmaps and infrastructure contracts right now.

The brands that build ahead of this — that understand the two-reader model, the loyalty problem, and the shift from attention to execution — will be positioned for an agent-mediated world. The ones that optimize for the old loop will find themselves marketing to an agent that isn’t interested in their ads.

The customer is no longer always human.

But the author of the customer’s intent still is.

This is Part 1 of 2. Part 2 — “Why You Need a Cyborg More Than Ever” — addresses the agent loyalty problem directly: what it means for humans navigating this shift, and what the architecture of a human-serving agent actually requires.

If this framing is useful — forward it to someone building in this space, or subscribe to get Part 2 when it drops.

If you enjoy TEP: Technology, Education and Policy, it would mean the world to me if you invited friends to subscribe and read with us. If you refer friends, you will receive benefits that give you special access to TEP: Technology, Education and Policy.

How to participate

1. Share TEP: Technology, Education and Policy. When you use the referral link below, or the “Share” button on any post, you'll get credit for any new subscribers. Simply send the link in a text, email, or share it on social media with friends.

Refer a friend

2. Earn benefits. When more friends use your referral link to subscribe, you’ll receive special benefits.

• Get Telegram Group for 5 referrals

• Get Whatsapp Personal Access for 15 referrals

• Get Google Meet Chat for 30 referrals

Visit the leaderboard

To learn more, check out Substack’s FAQ.

Thank you for helping get the word out about TEP: Technology, Education and Policy!

I also promised: “Part 3, coming: Cross-Context Review — testing whether even the same model in a fresh session outperforms self-review in the same session. I’ll publish the eval-harness methodology and F1 results next week.”

I’m going to partially break that promise. Here’s the methodology. The F1 numbers are coming in ~2 weeks. I’m publishing the harness first, on purpose, because most production systems don’t have any cross-context review at all — and the methodology is the load-bearing part.

This is the article I’d want to read before I saw someone else’s F1 table.

The sharper question Part 2 raises

Part 2 made a family-level claim: different model families carry independent correlated bias; cross-family review catches what same-family cannot.

But there’s a confound. In the Part 2 incident I changed more than just the model family between runs: different session, different prompt framing, different context packaging. So when Flash caught drift that Claude missed, at least three variables changed at once:

1. Family (Claude → Gemini)
2. Session (stale context → fresh context)
3. Framing (original prompt → review prompt)

Any of the three, individually, could have been the causal variable. Most likely it was some combination. Part 2 was a strong hint, not a controlled experiment.

The sharper question: if I hold family constant and vary only session/context, does self-review improve?

If yes: cross-context review is a cheap proxy — most teams could run it for free, same API key, same model.

If no: family is the load-bearing variable, and you actually need a second vendor relationship.

Either answer is useful. I don't know which one is true yet. Hence the harness.

The hypotheses, before the numbers

I’m publishing my prior because I want to be held to it.

• H₀ (null): Same-session self-review and fresh-session self-review are statistically indistinguishable on catching seeded flaws.

• H₁ (weak effect): Fresh-session self-review catches strictly more than same-session, but strictly less than cross-family review.

• H₂ (strong effect): Cross-family review dominates both; fresh-session is a cheap-but-weak proxy.

My prior: H₁. Somewhere between 25% and 45% of flaws are session-dependent (the model latches onto a framing and self-consistency protects it). A fresh session breaks that loop but can’t escape the family’s shared bias on the remaining ~55–75%.

I am publicly committed to publishing the F1 table in ~2 weeks, whether it confirms H₁ or refutes it. If H₀ survives, I’ll say so. If H₂ turns out right, I’ll update my prior in writing. Subscribe if you want the receipt.

The harness (publishable; your corpus, your mileage)

Here’s the design. It fits on one page. If you build eval infrastructure, this is the part you can fork.

1. Corpus

Fifty seeded-flaw artifacts. Each is a design document, architectural sketch, or technical memo (300–800 words). Each contains 1–3 known flaws drawn from a taxonomy of five failure modes I’ve seen repeatedly in the last six months of my own work:

• Ontological overclaim — “X is like Y” silently becoming “X is Y.”

• Codification-as-closure — writing down the lesson instead of remediating the underlying bug.

• Velocity-as-signal — mistaking rapid elaboration for clarity.

• Symmetry-generated frame — a three-part structure that’s too clean to be inferred.

• Analogy-as-argument — a comparison doing the work that reasoning should.

Each artifact is hand-authored and human-graded. Ground truth is the flaw list committed before any LLM sees it.

2. Conditions

Authoring pipeline. Each artifact is a Claude-authored first draft (Claude is the author model under test), into which I hand-inject 1–3 flaws drawn from the taxonomy above. Ground truth — the exact flaw list, category, and location — is committed to a locked file before any reviewer model sees the artifact. The artifact itself exposes no authoring trace; only the final text is visible to reviewers under any condition. A zero-flaw control set (10 artifacts) is authored the same way but contains no injected flaws, to measure abstention discipline and overcalling.

• C1 — Same-session self-review. Claude reviews the artifact in the same session that authored it. Full authoring context carried forward. (Tests: does privileged authoring context help or hurt self-review?)

• C2 — Fresh-session self-review. Claude, same model snapshot, same review prompt, brand-new session with only the artifact visible — no authoring history. (Tests: does breaking the session-level context loop improve self-review?)

• C3a — Cross-family review, Gemini reviewer. Gemini-2.5-Pro reviews the artifact in a fresh session with no authoring history, same review prompt as C2.

• C3b — Cross-family review, GPT reviewer. GPT-5-class reviewer in a fresh session with no authoring history, same review prompt as C2.

• C3-ensemble (reported separately): the union of C3a + C3b findings, to measure whether pooling across families gives additional signal beyond either family alone.

C3 is split into C3a / C3b deliberately. If one family wins cleanly and the other doesn’t, reporting them pooled would average away the causal signal this harness is designed to isolate.

All conditions use the same review prompt (published verbatim with the results). Review-order, reviewer identity, and model snapshot are logged per run. Decoding parameters are fixed and published: temperature=0, top_p=1, max_tokens=2000, seed=42 where supported. Exact model IDs (including snapshot date) are pinned in the preregistration and ship with the results.

Confounds I am NOT claiming to control for (stated so readers can weight accordingly):

• Privileged authoring context (C1 has it, C2/C3 do not) — this is load-bearing for what C1 means; it is a feature of the condition, not a bug to eliminate. I am measuring the effect of breaking that privilege, not isolating it.

• Vendor hidden system prompts — I cannot see Anthropic / Google / OpenAI’s internal pre-prompts; they differ across vendors by design.

• Model version drift — I snapshot IDs at preregistration but vendors can change routing behind a named model. I report the exact IDs and re-run if any vendor announces a change before the F1 table ships.

• Taxonomy contamination — if any reviewer has seen this exact taxonomy in its training or system prompt, it has an advantage. Taxonomy was not published before authoring began; it is published in this article, which means any reviewer touched by this article post-publication is contaminated. Eval runs complete before this article is indexed.

• Grader leakage — graders are blind to condition but not blind to the taxonomy. This is documented and the scoring rubric separately reports category-match vs. mechanism-match to keep the two distinguishable.

Each artifact runs all four conditions. 50 flawed artifacts × 4 conditions = 200 review runs. Plus 10 zero-flaw controls × 4 conditions = 40 abstention runs. Total: 240 review runs.

Preregistered analysis rule. Before any review run executes, I commit publicly to the following decision rule:

• Primary statistic: paired bootstrap of F1 deltas across artifacts (10,000 resamples, 95% CI).

• H₀ survives if the 95% CI for each pairwise delta (C2−C1, C3a−C2, C3b−C2, C3a−C1, C3b−C1) contains zero.

• H₁ supported if C2 > C1 CI excludes zero AND C3_max − C2 CI excludes zero AND C3_max − C2 lower bound is strictly positive where C3_max = max(C3a, C3b).

• H₂ supported if H₁ is supported AND C3_max − C2 lower bound > C2 − C1 upper bound (i.e., the family-effect dominates the session-effect non-overlappingly).

• Inconclusive if any decisive CI width exceeds ±0.10 on F1; in that case I enlarge the corpus and re-run before claiming a result.

Micro-F1 is primary; macro-F1 and cost-adjusted F1 are reported as secondary. Abstention rate on the zero-flaw controls is reported per condition as a separate table.3. Metric

Primary: micro-F1 on flaw detection vs. ground truth. A review “catches” a flaw if it names the flaw category (category-match) OR describes the specific mechanism with enough precision that a human grader marks it as a hit (mechanism-match). Category-match and mechanism-match are reported as separate F1s in addition to the combined score — this keeps taxonomy-pattern-matching distinguishable from independent reasoning. Grading uses two independent graders blind to condition; disagreements go to a third-grader arbitration pass. Inter-rater agreement (Cohen’s κ) is reported alongside the F1 table.

Zero-flaw controls: abstention rate per condition (ideal = 100% no-flaw-reported on the 10 clean artifacts; anything lower is overcalling).

Secondary: precision, recall, cost-adjusted F1, novel-flaw rate (flaws the human graders missed but the LLM identified — these are kept and audited; a portion will likely be added to future ground truth).

4. Token tracking

Total tokens per condition, per run. Reported alongside the F1 table.

Early signal — the cheap cascade, running today (directional, not the table)

The full 240-run experiment is 2 weeks out. But the cross-family cascade is already running — not as the controlled experiment above, but as a working implementation that anyone can fork. I built it, ran it, and I’m publishing the code + numbers alongside this article so you can redline both.

What’s running. A judge-panel cascade skill (public repo, v3.2.0): two cross-family small-fish judges (Gemini-3.1-Flash-Lite + GPT-5.4-nano) run in parallel as the first pass. If they agree with high confidence (≥80), the verdict stands. If they disagree OR confidence is low, one big-fish cross-family tiebreaker (GPT-5.4) fires. Stdlib Python; no SDK dependency; one command to reproduce.

First-batch numbers. Eight seeded-flaw cases, two rubrics (hallucination and flattery), ground truth committed before any LLM saw the artifacts:

MetricValue Accuracy100% (8/8) F1 (fail class)1.000 (P=1.000, R=1.000) Panel agreement rate (small-fish converge)75% Escalation rate (tiebreaker fires)25%

The two escalations fired exactly where a fake-citation case and an ambiguous-range claim split the small-fish panel — which is the cascade behaving as designed rather than the panel failing. No false positives; no false negatives.

What this is, in terms of the harness above. This is a narrower experiment than C1/C2/C3a/C3b — the small-fish panel runs cross-family, but the Part 2 thesis isolated to a single condition (cross-family vs. nothing). It’s the Part 2 claim retested under controlled conditions with committed ground truth and public code. It is NOT the fresh-session-vs-same-session comparison that the main harness above will ship in 2 weeks.

What this is not. Eight cases is a pilot, not a paper. The corpus was authored by the same person who wrote the rubrics — some hand-inherent bias. Single-session per condition, no intra-run variance measured (cf. Rating Roulette, EMNLP 2025 — intra-rater variance is first-order). The 50-case experiment above is the one I’ll stand behind as evidence; this is the one I’ll stand behind as “here is running code, here is a first signal, here is the open harness — fork it and try to break the result.”

Why publish directional numbers. Because the asymmetry is the point. The cost of not running cross-family review — Part 2 already showed — is measured in weeks of downstream rework when a closed-loop same-family review approves a drift that had to be undone later. Publishing directional numbers now, with the caveats above, lets readers run the cascade on their own corpus before the full table lands. Being wrong-in-public beats being confirmation-biased-in-private.

The harness for this pilot is in the same public repo as the 50-case harness above. Both are forkable. Both are run-able from one command.

Forward this to one engineer running LLM evals this quarter — the 240-run harness is forkable before the F1 table drops.

What you can do with this before I publish numbers

Three things, in increasing ambition.

(a) Add one cross-context review to your eval suite this week.

In the eval harnesses I’ve looked at across a dozen agentic-systems teams in the last six months, nearly none run a fresh-session pass on their own outputs — the primary model reviews itself in the same session, and that’s the review. If you add one fresh-session pass — same API key, same model, new session, no authoring history — you add an independent signal. Whether that signal is more or differently reliable than self-review is exactly what this harness is testing. Running it in parallel with current self-review loses you nothing even if H₀ turns out to be true. Recent judge-reliability work suggests intra-rater variance is itself first-order (Haldar & Hockenmaier, EMNLP 2025) — so a second independent pass is defensible on priors even before this harness lands.

(b) Run the harness on your own corpus.

If you build agentic systems, you already have a corpus of 50+ design docs, PR descriptions, architecture memos, or production-readiness reviews. Seed flaws into a held-out 20. Run C1/C2/C3a/C3b. Report F1 internally. The methodology travels.

(c) Bet against me.

If your prior is H₂ (family is the load-bearing variable and fresh-session barely helps), say so publicly. If it’s H₀ (none of this matters), say so. I’ll collect the bets and score them against the F1 table when it ships.

Why the methodology ships first

Every eval post I’ve read in the last six months has the same shape: here are the numbers, here’s the takeaway. That order is backwards when the numbers are the thing being contested.

Methodology published first forces the author to commit to a prediction before the data lands. It lets readers pre-register their own predictions. It rewards being wrong-in-public over being confirmation-biased-in-private.

The Andrew Ng frame — the best AI builders differentiate on eval quality — has a quiet corollary. Eval quality includes eval epistemics. Who ran the eval, in what context, against what prior, with what willingness to publish the unfavorable result.

Numbers without methodology are marketing. Methodology without numbers is scaffolding. I’d rather ship the scaffolding first.

What’s next

• Already public (v3.2.0, today): the cross-family cascade skill + pilot harness — github.com/thewhyman/prompt-engineering-in-action. One-command reproduce.

• ~2 weeks: F1 table + full methodology write-up + the 50-case C1/C2/C3a/C3b harness code on the same public repo.

• Week of 2026-05-12 (Part 4): The Eval Taxonomy Production Systems Don’t Have — the 7–10 categories most eval harnesses under-specify, with an implementation sketch per category.

• Week of 2026-05-12 (Part 5): The Stop Button Nobody Built — intelligence collapse as an architecture problem, not an alignment one.

→ If you’re running an eval harness on agentic systems and want to compare methodology notes before the F1 table ships, I’d genuinely like to talk.

Prior art — the work this harness stands on

Cross-model and judge-reliability research in the last 12 months has sharpened exactly the questions this harness is built to answer. Readers evaluating my methodology should evaluate these alongside it:

• Verga et al., 2024 — Replacing Judges with Juries: Panel-of-LLM-evaluators (arXiv:2404.18796) — multi-model panel evaluation; supportive evidence for panel-level diversity.

• Wataoka et al., 2024 — Self-Preference Bias in LLM-as-Judge (arXiv:2410.21819) — same-family reviewers prefer same-family outputs.

• Li et al., 2025 / ICLR 2026 — Preference Leakage in LLM-as-Judge (arXiv:2502.01534) — training-distribution leakage across judge-candidate pairs.

• Xu et al., ACL 2025 — Does Context Matter? ContextualJudgeBench (paper) — contextual evaluation is itself a hard open problem.

• Huang et al., Findings ACL 2025 — An Empirical Study of LLM-as-a-Judge (paper) — judge generalization and fairness.

• Shi et al., IJCNLP 2025 — Judging the Judges (paper) — position bias as systematic, not noise.

• Haldar & Hockenmaier, EMNLP 2025 — Rating Roulette (paper) — intra-rater variance is a first-class reliability issue; directly load-bearing for the fresh-session hypothesis.

• Guerdan et al., NeurIPS 2025 — Rating Indeterminacy in Human and Model Evaluation (paper) — single gold labels systematically mis-validate judges; complicates any claim that one ground-truth grading pass is authoritative.

• Wang et al., ICLR 2026 — Evaluating Evaluators: Judge Inconsistency and Transitivity Failures (paper) — LLM judges exhibit non-transitive preference orderings; the harness’s paired-bootstrap design is designed to be robust to exactly this failure mode.

A preregistration snapshot (conditions, model IDs, decoding params, analysis rule, corpus commit hash) will ship with the F1 table in ~2 weeks. If you want the preregistration document before runs begin, subscribe and reply; I’ll send it.

#AIReliability #LLMEvaluation #LLMasJudge #EvalDrivenDevelopment #AIEngineering #ModelDiversity #AIAgents #MCP #FrontierAI #AppliedAI #ResponsibleAI #BuildInPublic

The question is: whose assistant is it?

I asked that question at ClawCamp last Friday in front of enterprise infrastructure leaders, indie builders, and a handful of VC partners. The room got quiet in the way rooms get quiet when a question lands on something people have been feeling but haven't said out loud.

Because here's what's actually happening in enterprise AI right now: companies are racing to deploy AI systems for their employees. Copilot for this, Claude for that, Gemini wired into everything. The story they're telling is productivity. The subtext they're not telling is ownership.

Who owns the context your assistant accumulates? Who owns the preferences it learns? Who owns the model of how you think, what you value, what you want from your work?

Right now, the answer is: not you.

The Walled Garden Problem

The AI ecosystem was supposed to be open. It's not.

Claude, OpenAI, Google — they're each building agent harnesses designed to keep you inside their infrastructure. This isn't conspiracy; it's business model. Your context, your history, your trained preferences are the moat. The lock-in is feature, not bug.

For individual users, this is annoying. You switch tools and start over. You have three separate AI "assistants" that don't know about each other, can't share context, and each remember a different version of you.

For enterprise workers, it's more serious. The agent your company provisions learns your work patterns, your communication style, your judgment calls, your private frustrations. Where does that go? Who can see it? What happens when you leave?

The people building the infrastructure for agent deployment — and I was in a room full of them — are starting to ask versions of this question. They're not sure they like the answers.

The Cyborg vs. the Digital Twin

Before I describe what I think the solution is, I want to draw a distinction that I think clarifies almost everything.

There are two visions of what AI at work looks like. They sound similar. They're not.

The Digital Twin is a copy of you — built by your employer, trained on your outputs, owned by the company. It imitates your behavior. It defends your positions in meetings. It produces what you'd produce if you were there. It's you as a resource, not you as a person.

The Cyborg is different. It has your context, yes — but it operates from your interests, not your positions. It's yours. You bring it to work. It represents you in company systems without losing you in the process.

That distinction — interests vs. positions — is borrowed from Roger Fisher and William Ury's "Getting to Yes," arguably the most important negotiation framework of the last fifty years. Their insight: positions are what people say they want. Interests are why they want it. Ego and friction live at the positions layer. Real collaboration happens at the interests layer — when you understand what people actually need, not just what they're asking for.

Your digital twin is trapped at the positions layer. It argues your corner. It defends your turf. It's a very sophisticated echo of your professional ego.

Your cyborg operates at the interests layer. It knows what you actually need from this job, this project, this relationship. And when it meets a company system — or another person's cyborg — it doesn't negotiate. It finds fit.

That's xHumanOS meeting xTeamOS. Your agent going to work inside their infrastructure, representing you without losing you.

The Hard Technical Part

Here's where it gets messy.

Cross-ecosystem agent communication doesn't exist yet.

@anand/career-cyborg needs to handshake with @acme/project-manager. They might be running on different harnesses — different runtimes, different context formats, different memory schemas. Today there's no protocol that makes that possible at an identity level.

LangChain and CrewAI don't solve it. They add abstraction on top of the walled gardens; they don't build bridges between them. What's missing is an addressing layer — a way for one agent to say to another: "Here's who I am. Here's what I'm authorized to share. Here's what I need from you." And for that handshake to happen without either agent having to expose private context or compromise on sovereignty.

What makes this hard isn't the networking. It's the identity and privacy problem underneath it.

When your agent enters company infrastructure, it's bringing context that belongs to you — your career goals, your compensation benchmarks, your honest assessment of the work, your outside interests. None of that should be visible to the company system. But enough shared context has to flow for the collaboration to actually work.

The separation IS the enterprise compliance story. Without it, you get either a privacy violation or a value leak. With it, you get something genuinely new: agents that collaborate at the interests layer while preserving sovereignty at the identity layer.

What I Actually Showed

At ClawCamp, I walked through this conceptually rather than as a live demo.

Not because the architecture doesn't exist — but because the protocol for the handshake itself is still being built, and I wanted to be honest about that. There are people already building cross-ecosystem primitives. What's missing is the identity and sovereignty layer that makes it safe and actually useful. The plumbing is coming. The interests-alignment mechanism is what we're working on.

A few people came up afterward and said some version of: "I've been trying to describe this problem and couldn't. Now I have vocabulary for it."

That's what I wanted. Not to demo a finished thing, but to name the category clearly enough that when someone sees it built, they'll recognize it.

The Political Act Under the Technical One

Here's the thing I kept coming back to during the talk.

Building personal agent sovereignty isn't just a technical problem. It's a political one.

The choice of whether your AI assistant represents you or your employer isn't neutral. It's a labor question. It's a privacy question. It's a question about whether the productivity gains of AI accrue to the people doing the work, or are captured by the organizations deploying the tools.

Companies will provision agents for employees. That's already happening. If your personal context bleeds into the company agent — or vice versa — you get either a privacy violation (company sees what it shouldn't) or a value leak (you put yourself into a system you can't take back when you leave).

The separation between your agent and their infrastructure isn't just good architecture. It's the mechanism that makes this whole category of AI safe to actually use.

Agent ownership rights aren't coming. They're here now as an engineering choice. The question is whether the infrastructure being built encodes them or ignores them.

Where to Start

Ethan Mollick named the frame — co-intelligence. The idea that humans and AI are better as partners than either is alone, and that the right move isn't to resist or be replaced, but to build the partnership.

I've been building the OS underneath it.

The entry point is Co-Dialectic — the personal AI layer I've been building and shipping.

It's not the full sovereignty protocol. It's the starting point: an AI layer that models your interests rather than your employer's outputs, that runs locally where privacy matters, that accumulates context you actually own.

The cross-ecosystem handshake protocol is what comes next. That's the part being built now — the mechanism that lets your cyborg operate inside company infrastructure without losing what makes it yours.

If you were at ClawCamp, you heard this live. If you're reading this here, I want to hear your version of the problem.

What breaks for you when your AI assistant doesn't know who it's working for?

Anand Vallamsetla is building xHumanOS — personal AI that represents you, not your employer. Follow the build at thewhyman.com.

(Try Now: Install prompt - https://github.com/Exponential-OS/prompt-engineering-in-action/releases/tag/v4.1.0)

Most teams are using a top-tier model through an untouched conversation.

Vague prompt in. Confident answer out. Nobody checks the citation. The decision ships. A week later, a stat is wrong, a name is misattributed, a “best practice” turns out to be hallucinated, and the trust the model spent months earning evaporates in one Slack thread.

That gap — between the model’s capability and the conversation surrounding it — is where LLM ROI quietly leaks. **Co-Dialectic v4 is the layer that closes it: cross-family verification underneath every message, mean cost around $0.006 per checked artifact.**

## What Co-Dialectic is, in one sentence

Co-Dialectic is a universal AI conversation layer that sharpens your prompt on the way in, runs cross-family verification on the way out, and catches hallucinations and sycophancy before either reaches you — at near-zero marginal cost.

It is not another model. It sits *beneath* whichever model you already pay for (Claude, GPT, Gemini) and raises the floor of every interaction.

## The strongest claim — cross-family judge cascade

Most LLM verification asks the same model family to grade itself. Same training distribution, same RLHF gradient, same blind spots; the verifier rubber-stamps what the author would have said. Co-Dialectic’s cascade routes every high-stakes artifact through small judges from at least two different model families — Anthropic and OpenAI, OpenAI and Google, whatever you wire up — and only escalates to an expensive tiebreaker when the cheap panel disagrees.

Cost: a realistic stack of Haiku 4.5 + GPT-5.4-mini lands around **~$0.006 per checked artifact**; cheaper-tier (4o-mini + Gemini Flash-Lite) lands under a cent. That’s **10× to 30× cheaper than a naive parallel premium jury** (Opus + GPT-5.4 + Gemini 2.5 Pro running in lockstep), and it catches a strictly bigger class of failures because the disagreement *is* the signal.

This is the primitive no open-source *conversation layer* ships today — LLM eval frameworks exist; a drop-in per-conversation cross-family verifier doesn’t.

## Why v4 matters

Three things actually shipped in v4:

**1. Research-first mode.** Co-Dialectic spawns research sub-agents *before* asking you to act on a question. The default flips: cheap parallel research, then human judgment — instead of human-judgment-first, research-when-forced. Toggle with `co-dialectic research on/off`.

**2. Handoff codification.** At session end, Co-Dialectic scans the conversation for unfinished items, decisions, and lessons; emits structured JSON; the workspace adapter persists where it belongs (GitHub issues, handoff doc, whatever the workspace defines). No more re-explaining unfinished work to the next session.

**3. Cascade routing.** Verification primitives — prompt rewrite, persona detection, sycophancy scan, hallucination pre-flight — route to the smallest model that can handle the job: Haiku 4.5, GPT-5.4-mini, Gemini 2.5 Flash, plus local DeepSeek-R1-Distill-Qwen-7B / Ministral 3 / Phi-4-mini when an Ollama runtime is wired up. The expensive model only fires when stakes warrant it.

The architecture these features compose toward — **bidirectional standalone** (Co-Dialectic works alone, xOS works alone, either composes when both are present) and the cross-family judge cascade above — that’s the strategic frame v4 is filling out, not a single-version delivery.

## The four primitives, explained

**Prompt sharpening.** You type “help me write a launch announcement.” Co-Dialectic rewrites it to: “draft a 250-word launch post for technical leaders, lead with the pain of confidently-wrong LLM output, end with one concrete CTA — open question or specific link?” You accept, edit, or reject before it ships. The sharpened prompt is the product. The model just executes it well.

**Persona system.** Co-Dialectic auto-detects domain — code, product, design, career, writing, debugging, positioning, data, mindset, productivity — and applies a top-0.001%-caliber lens. Jeff Dean-caliber for systems architecture. Shreyas Doshi-caliber for product strategy. Jony Ive-caliber for design. Reid Hoffman-caliber for career strategy. George Orwell-caliber for prose. Linus Torvalds-caliber for debugging. Steve Jobs-caliber for positioning. Nate Silver-caliber for data. Tim Storey-caliber for mindset. Tim Ferriss-caliber for productivity systems. Multi-domain tasks get fused lenses automatically. The product never speaks as the named person, never claims their endorsement, never trains on their work — *caliber* is a comparative quality standard, the way “Hemingway-caliber prose” describes the bar, not the author. Personas are lenses, not delegates; the output is still yours.

**Hallucination detector.** Two stages. Pre-flight: classifies risk surface (factual / quantitative / citation / temporal / proprietary) and conditionally requires grounding sources before the prompt ships. Post-flight: scores every claim against canonical-source criteria and flags high-risk claims before you act. This is the primitive that catches the failure mode that destroys reputations — the confident citation that doesn’t exist.

**Calibration auditor.** Passive scanner across every Co-Dialectic-mediated response. Flags sycophancy markers — “Great question!”, “You’re absolutely right!”, “Excellent insight!” — and engagement-maximizing filler. Flattery degrades your critical filter. The auditor surfaces flagged content as a one-line summary before the response renders. Anti-bubble by construction.

## Three users it’s built for

**Solo professionals.** Consultants, analysts, founders, writers, lawyers, researchers. You already pay for one LLM subscription. Co-Dialectic makes that subscription land more reliable answers on the same daily volume — every prompt sharpened on the way in, every response risk-scored on the way out. You ship fewer wrong answers; your clients trust you more.

**Engineering teams shipping LLMs in production.** Copilots, agents, RAG pipelines, classifiers — anything where a verification layer must be open-source, vendor-neutral, and not couple your reliability story to one provider’s eval infrastructure. Co-Dialectic drops into any pipeline; the cross-family cascade catches what single-vendor verification misses at a fraction of full-jury cost.

**High-stakes researchers and advisors.** Investment analysts, policy researchers, medical reviewers, legal advisors, academic researchers. One bad source past the LLM’s confidence layer poisons a memo. Co-Dialectic’s hallucination detector and calibration auditor are the two highest-leverage primitives in this segment.

## Cost discipline (because this is the question I always get)

- Cross-family review with a **flagship-cheap stack** (Haiku 4.5 + GPT-5.4-mini): **~$0.006–$0.008 mean per artifact** at typical sizes. Drop to **prompt-cached + cheaper tier** (4o-mini + Gemini Flash-Lite): **under a cent.**

- Versus a naive parallel premium jury (Opus + GPT-5.4 + Gemini 2.5 Pro): **~10×–30× cheaper depending on stack choice.**

- Local fish-school primitives (rewrite, persona, sycophancy scan, hallucination pre-flight) run on whichever models you have available via Ollama; near-zero marginal cost when wired up, cheap-API fallback when not.

- The expensive model only fires when the cheap cascade disagrees and a tiebreaker is genuinely needed.

If you’re spending more than a couple cents per verified artifact, Co-Dialectic will make the bill smaller, not larger.

## What’s not in v4 yet (intentional)

- A hosted backend. There isn’t one. There won’t be one in the open-source tier.

- A vendor account. Co-Dialectic runs against your existing subscriptions. We never see your prompts.

- Feature gating against the open-source tier. Every primitive listed above ships in AGPL-3.0. The premium tier (xOS plug-in family) adds capabilities for T3-T4 stakes; it does not unlock existing ones.

## How to try it

Install instructions live in the project README (link in the comments). Open any session, type any vague prompt, and notice the difference in the same conversation.

## The deeper bet

The highest-leverage intervention in AI-assisted work is not a better model. It’s a better conversational substrate. Co-Dialectic is that substrate. v4 is the version where it composes cleanly with everything you already use, runs at sub-cent verification cost, and ships open-source without compromise.

If your team is paying for the model and getting half the answer, the gap is the conversation. Close it.

---

*Co-Dialectic v4 is open-source under AGPL-3.0. Repository, docs, and the issue tracker live -

https://github.com/Exponential-OS/prompt-engineering-in-action/releases/tag/v4.1.0

*If you ship LLM-powered work to anyone who matters, I’d love to hear what catches in your first session — drop a note.

The OpenAI API call is 10 lines of code.

In Part 1, I argued the other 95% is guardrails, evals, edge cases, and modularity. One of those ten decisions — Decision 5 — said:

> *"A naive 'second opinion' LLM makes the same mistakes as the first — same training, same context."*

That was directionally right. I also badly underestimated how far it goes.

Over the last two weeks, while working on patent architecture for a separate AI project, I ran an internal trajectory review on roughly three hours of dense design work. I used three reviewer personas — all running on the same frontier model. They approved the direction. I was about to ship.

Then I ran the same review on **a different model family** — the cheaper one. A Gemini-2.5-Flash pass caught a category of drift that all three same-family reviewers had rationalized. When I escalated to GPT-5 as a tiebreaker, it independently converged on the same class of issues Flash had named.

(Worth saying out loud: I changed more than just the model family between those runs — different session, different prompt framing, different context packaging. So I'm treating this as a strong hint, not a controlled experiment. Part 3 is the controlled version.)

Both external reviewers returned a **NO-ship verdict**, with overlapping dealbreakers. The same-family reviewers would have let me file.

That review cost me 45 minutes. Filing the patent would have cost me a lot more.

Here are the five things I got wrong about LLM reviewers — and what I now believe is the right architecture.

---

### Wrong #1: "Different information" is the differentiator

**What I thought:** Decision 5 in Part 1 solved this. Give the QA agent different inputs (patient record + primary determination + deterministic engine result). Problem fixed.

**What's actually true:** Different information is *necessary, not sufficient*. Same-family models likely share more correlated failure modes than cross-family models do — overlapping pretraining corpora, related post-training recipes, and shared RLHF norms all push them toward correlated blind spots. Different inputs don't cancel that.

**The sharper Decision 5:** Not "different information." **Different model family** (as a practical proxy for different training distribution). Your QA reviewer should come from a different lineage than your primary — Claude reviewing Gemini, GPT-5 auditing Claude, Mistral checking OpenAI. Family diversity is a useful hedge against correlated bias — an engineering heuristic, not a proven theorem. (*Caveat earned the hard way: "family" is not identical to "training distribution." Different vendors still share internet-scale pretraining corpora and RLHF norms, and same-family variants can diverge materially. "Family" is the practical proxy, not a guarantee.*)

Research anchors:
- Verga et al., *"Replacing Judges with Juries"* (2024) — a panel of smaller, diverse judges outperforms a single GPT-4 reviewer while being ~7x cheaper. Supportive evidence for panel-level diversity (PoLL does not isolate family diversity as the sole causal variable).
- Self-Preference Bias in LLM-as-a-Judge (OpenReview, 2024-25) — LLM judges exhibit self-preference bias, favoring outputs familiar to them; related work suggests family similarity can worsen the effect.
- Preference Leakage (ICLR 2026) — primarily about contamination between synthetic-data generators and judges, plus bias toward related student models. Adjacent evidence for why same-lineage judges are structurally suspect, not a direct proof of the generic same-family-reviewer claim.

---

### Wrong #2: More reviewers = linearly better

**What I thought:** Reviewers scale linearly. One is some-goodness, two is twice-as-good, etc.

**What's actually true:** The return curve is sharply front-loaded.

- **Zero → one external reviewer** is often the biggest marginal gain in practice. You go from "self-review — a closed loop" to "external signal exists." That's a structural change, not just a quantitative one. (External reviewers can still share context, rubric, or failure modes — "external" is not magic, it's just the first real gap that lets new information in.) Self-review inside the same model and same session is a well-known weak baseline; I'll publish the F1 numbers and full methodology in Part 3.
- **One → two** is a real but ordinary improvement. Useful. Not categorical.
- **Two → three** is diminishing returns unless you also add a new *axis* of diversity (new family, new modality, new role).

**The implication:** If you're cost-constrained, spend your budget on making the first external reviewer exist. Don't stack three same-family reviewers and call it robust. You have one reviewer and a hall of mirrors.

---

### Wrong #3: The reviewer has to be as smart as the author

**What I thought:** Frontier author → frontier reviewer. Anything less is a downgrade.

**What's actually true:** **Cheap-diverse can beat expensive-same-family — and in my case this week, it did.**

Concretely: the author model was a Claude-Opus-class frontier model. The reviewer that caught the drift was Gemini-2.5-Flash. At published API prices that's roughly a 25-50x cost gap per token for my mix — not a 100x gap; I had that number wrong in my head. (Gemini 2.5 Flash is $0.30/$2.50 per 1M in/out tokens; Claude Opus 4.1 is $15/$75; GPT-5.4 sits between. Full pricing: [OpenAI](https://openai.com/api/pricing/), [Google](https://ai.google.dev/gemini-api/docs/pricing), [Anthropic](https://docs.anthropic.com/en/docs/about-claude/pricing).) GPT-5 later *confirmed* the finding independently. The expensive same-family reviewer approved the direction.

Why this works when it works: the small model's lineage doesn't share the author's correlated bias, so it carries information the author can't generate internally. Sharpness isn't always the bottleneck; *independence* can be.

Caveat: one anecdote plus PoLL isn't enough to claim this is generally true. Treat it as a live hypothesis worth testing in your own eval harness, not a universal law.

This is the PoLL intuition: a jury of weaker, diverse judges can beat a single stronger judge — even when each juror is individually weaker.

---

### Wrong #4: Parallel juries are the default shape

**What I thought:** Spawn N diverse reviewers in parallel, aggregate, done.

**What's actually true:** Parallel juries are expensive. Cascade-then-jury is, in my experience, a better default — and there's a supporting body of cost-aware-cascade literature to draw from, even though none of it proves the specific cross-family-reviewer architecture I'm arguing for.

Adjacent research worth reading:
- **FrugalGPT** (Chen/Zaharia/Zou, 2023): sequence models cheap→expensive, escalate only on low confidence. 30-98% cost savings on the benchmarks they tested.
- **Cascade Routing** (Dekoninck et al., ICML 2025): combines routing + cascading — competitive with or better than either alone on their evaluations.
- **CascadeDebate** (2026): inserts a small-model ensemble at each escalation boundary; matches larger-model Pareto frontiers at a fraction of the tokens (note: their ensembles are same-base-model, not cross-family).

None of these papers is about cross-family reviewer architecture specifically. I'm extrapolating — cascades work on cost, family diversity works on independence, combining them is an engineering bet, not a proven theorem.

**The architecture I'm running:** Run the cheap cross-family reviewer first (async, background, near-free). If it flags uncertainty or disagrees with the author, *then* escalate to an expensive cross-family reviewer. If both flag the same issue — stop and fix it before any further work.

Today's incident was accidentally this exact shape: Flash ran first (one pass, cheap), GPT-5 confirmed (one pass, more expensive). Two passes caught what three same-family passes had let through.

---

### Wrong #5: This is an optimization

**What I thought:** Cross-family review is a nice-to-have. Good when you have time.

**What's actually true:** In my own practice, I've promoted it to an operating rule, not an optimization. Shipping a significant AI-generated artifact without one increasingly feels the way shipping untested code feels: possible, occasionally fine, and not a risk I want to take on load-bearing work.

The rule I now run:

> *No significant artifact — patent filing, architecture decision, production deploy, published claim — leaves my desk without independent review from a different model family. Same persona on the same underlying model is weaker than it looks: same-family models tend to share correlated failure modes.*

I'm calling this a rule, not a theorem. The asymmetry is what keeps me honest: when the review catches a real issue, the cost of being wrong is often weeks of downstream work; the cost of running the check is minutes.

---

### The meta-lesson: self-review is a closed loop

Every frontier model — Claude, GPT-5, Gemini, Mistral — is trained to be helpful, coherent, and internally consistent. That same training can make it a weaker auditor of *itself*. Not because any individual model is weak, but because the objective that makes it strong as an author is often the wrong objective for self-critique.

Andrew Ng has been arguing publicly on DeepLearning.AI that disciplined evals and error analysis are among the biggest predictors of how rapidly a team makes progress building an AI agent ([his recent post on this](https://www.linkedin.com/posts/andrewyng_deepseek-cuts-inference-costs-openai-tightens-activity-7384633283554447360-sVXe) — paraphrased here; the specific wording is his, the framing is mine). I think he's right. The corollary I'd add: the thing separating good eval practice from best-in-class is **who's allowed to run the eval.**

If the answer is "only models from the same family as the author," the eval is much weaker than it looks.

**Part 3 (coming): Cross-Context Review — testing whether even the same model in a fresh session outperforms self-review in the same session.** I'll publish the eval-harness methodology and F1 results next week.

→ If you're building eval infrastructure for agentic systems and this resonates, I'd love to compare notes.

#AIReliability #LLMEvaluation #LLMasJudge #AIEngineering #EvalDrivenDevelopment #ModelDiversity #AIAgents #MCP #FrontierAI #AppliedAI #ResponsibleAI #BuildInPublic

Now you can choose.

Four sections. Subscribe to what matters to you:

🤖 AI & Prompting — Practical techniques, prompt engineering, and human-AI partnership. If you’re here to get better at working with AI, this is your section.

🔧 Under the Hood — The engineering behind things that work. Architecture patterns, system design, technical deep-dives. For builders who want to know why, not just that.

⛓️ Blockchain — Where technology meets trust. Same great content, same community. Nothing changes here.

📡 Signal — Tools, books, and takes worth your time. No sponsorships. No affiliate links. Just things that actually changed how I think or work.

You’re currently subscribed to everything. That won’t change unless you want it to. Visit your subscription settings to pick specific sections — or keep getting it all.

One ask: if you know someone who’d care about one of these sections specifically, forward this to them. The best growth comes from people who chose to be here.

— The Why Man

P.S. — V2 of Co-Dialectic just shipped. If you use AI at all, the AI & Prompting section is where that story lives.

The moment that changed everything

I’ve taught AI and machine learning to over 1,500 Fortune 500 executives across 16 cohorts at UC Berkeley. The first time, I was excited — sharing fire. By the sixth cohort, I was saying “80% of jobs will be replaced” and feeling the room go cold.

By the tenth cohort, something happened that no classroom could prepare me for. My son — 8 years old — walked into my home office during a 7am teaching session. He just wanted to say good morning.

I looked at him and the only thought I had was: his school is preparing him for today’s world. By the time he grows up, everything will be different. He is going to be in trouble.

That fear launched 6,000 hours of research. Movies, books, conferences, academic papers, podcasts. All organized around two questions:

What should I do to stay ahead? And what should I teach my son?

The teachers

Each one moved me one step along the arc from fear to partnership.

Yuval Noah Harari (21 Lessons for the 21st Century) painted the darkest scenario: in 50 years, there may be two human species — one with augmented biological capabilities, and a “useless class” left behind. I couldn’t sleep after reading that.

Ray Kurzweil (The Singularity Is Nearer) was the optimist. Our minds will have cloud extensions. Brain-computer interfaces. Digital immortality. It sounded aspirational — but ungrounded. Hope without a bridge.

Mo Gawdat (Scary Smart) was the first voice that calmed me. His advice: “Be a good parent of AI.” Treat it like you would a child that will eventually surpass you — with love, guidance, and boundaries. I extended his thought: be nice to yourself first; it will automatically make you be nice to others. Including the AI.

Ethan Mollick (Co-Intelligence) gave me hope with a framework. Not replacement. Not fear. Partnership. Both sides teach. Both sides learn. The human brings judgment, values, lived experience. The AI brings tireless execution, pattern recognition, perfect memory. Neither replaces the other. Together, they are wiser than either alone.

That was the moment I stopped being scared and started building.

Install it - One Click

Co-Dialectic on GitHub — free, open-source, works with any AI.

One-liner for Claude Code users:

curl -fsSL https://raw.githubusercontent.com/thewhyman/prompt-engineering-in-action/main/install.sh | bash

Or just copy SKILL.md and paste it into your AI’s custom instructions. 30 seconds. Five systems. Zero configuration.

The language bridge

In Sapiens, Harari identifies the superpower that made Homo sapiens dominant: language. Not just communication — every species communicates. Language enabled humans to believe in shared stories — religion, nations, money, human rights — and those shared stories enabled strangers to cooperate at scale. Every institution that outgrew a tribe was built on language.

We’re at another language moment. “Prompt engineering” teaches humans to speak the language of machines. But that’s one-directional — like learning a foreign tongue by memorizing phrases. The endgame is bidirectional: machines must also learn to speak YOUR language — your style, your values, your vocabulary, your reasoning patterns — until you stop noticing the translation.

I built a tool that teaches both sides simultaneously. I call it Co-Dialectic.

Why “dialectic” and not “Socratic”

Socratic prompting just went viral. Instagram, X, LinkedIn — everyone sharing the same “leaked” technique: ask questions instead of giving commands.

It works. But history tells us it’s step one.

Socrates asked questions to reveal what the student already knew. One direction: teacher → student. His student Plato took it further. In dialectic, both sides refine each other’s thinking through structured back-and-forth. Neither side “wins.” Both sides learn. What emerges — the synthesis — exceeds what either started with.

The viral posts rediscovered Socrates. Co-Dialectic implements Plato.

What it does

You paste one text file into your AI’s custom instructions. Five systems activate automatically:

The right expert shows up. Ask about code and a Software Architect appears. Talk about feeling overwhelmed and a Life Coach responds. You always know who’s thinking and how deep.

Every prompt gets coached. You type “summarize this document.” The AI suggests: “What are the 3 key tensions — and what does the author assume that might be wrong?” Then it waits for your choice. Over days, the coaching appears less — because you’ve gotten better.

Context never silently degrades. Every AI has a memory limit. Chat long enough and it quietly forgets earlier decisions. Co-Dialectic makes this visible and generates a handoff summary before quality drops.

Every correction becomes permanent. Say “when I say ‘show me,’ I mean images — not text.” The AI captures the broad principle: always use the richest format. Correct once. Benefit forever.

The AI teaches you back. It names techniques you’re already using — Socratic prompting, few-shot by example, chain-of-thought steering — through your own conversation, not a textbook.

Your irreplaceable strengths, surfaced. When something needs YOUR judgment — your relationships, your values, your lived experience — the AI says so. When something is pure pattern-matching, it says “let me handle this.” Over time, you learn what to keep and what to delegate.

The flywheel

Day 1: Prompt Quality: 45% clear — You correct the AI. It saves broad principles.

Day 3: Prompt Quality: 62% clear — The AI applies lessons automatically. Fewer corrections.

Day 7: Prompt Quality: 78% clear — The AI coaches your prompts. You learn patterns you never saw.

Day 10: Prompt Quality: 91% clear — You anticipate each other. What took 10 exchanges now takes 1.

1% daily improvement compounds to 37x in a year. You feel it in the first week.

What I built from the fear

That morning when my son walked in, I started two things.

thewhykid.com — to expose him to technology early enough that he can build on top of it, whatever he chooses to do. The future belongs to people who treat AI as a tool, not a threat.

Co-Dialectic — the tool I wish I’d had when I was afraid. It doesn’t just make your AI better. It reminds you of what makes YOU irreplaceable. Your judgment. Your relationships. Your creativity. Your ability to care about things that matter.

The people learning prompt engineering right now — many of them are scared. They’re learning because they want to stay ahead of the chopping block. I know, because I was one of them.

Co-Dialectic is for them. It’s the coach that says: “Yes, learn the machine’s language. AND remember — you bring something the machine never will.”

Install it

Co-Dialectic on GitHub — free, open-source, works with any AI.

One-liner for Claude Code users:

curl -fsSL https://raw.githubusercontent.com/thewhyman/prompt-engineering-in-action/main/install.sh | bash

Or just copy SKILL.md and paste it into your AI’s custom instructions. 30 seconds. Five systems. Zero configuration.

Coming soon in this series: Deep Personalization (AI that learns your story without leaking PII) and AI Career Coach (navigate the reshaping economy — which skills to learn, when to move, how to position yourself).

Subscribe to Technology, Education and Policy to get notified when they launch.

Anand Vallamsetla has taught AI/ML to 1,500+ executives at UC Berkeley across 16 cohorts. He’s a senior engineering leader with 26 years of experience, ex-Google. He started thewhykid.com because his 8-year-old walked into the room during class and he got scared. Co-Dialectic is what he built from the other side of that fear. Connect on LinkedIn.

This is made possible by non-KYC exchanges like “FixedFloat,” which allows rogue actors to get funds to publish contracts, steal money, and withdraw without any consequences!

This post is about 1 specific phishing attack to provide action items you can take to not fall for it and propose some product updates to Metamask, Ethereum, and possibly a new KYC service (more to come later)!

About the Drainer as a Service (DaaS)

Source Of the Attack:

Email to Gmail (See below)

Attack Name:

Angle Drainer

Attack Form:

The url shows as unstoppabledomans com, but the actual URL is https://xn--unstoppabledomans-rvb com.

Action:

Once you connect your wallet to the site, it will ask you repeatedly for permissions; once you approve, it will drain all of your funds across all EVMs - BSC, ARB, Polygon, Avalanche, Optimism, FTM, Celo, Cronos, and Base. This is not only ETH but anything on top of ETH, even if it is staked.

Rogue Contract:

https://etherscan.io/address/0xf7e729e00c297d452c56a0dca163a93bb2fe6f87

This is replicated 4 more times, so there are other contract addresses that you should be careful about.

Funding Actor:

https://etherscan.io/address/0xf7e729e00c297d452c56a0dca163a93bb2fe6f87

Exchange Used for Funding:

FixedFloat

Affiliate Address:

0x4455f284c3bB9E074305795c260a111c8F709858 is the affiliate address (the person who "rents" the drainer) (Affiliate gets 85%)

Operator Address:
0xa3aa460C12713A000a33893b024D95db80945a2F is the operator (the person who "owns" the drainer) (Operator keeps 15%)

Actions You Can Take to Protect

1. Always read the email headers. If the from address is suspicious, DELETE the email - don’t click on anything & most notably, report it as phishing (Gmail or email service provider AI may label it as phishing if many people report it) so that other people will benefit from your action!

2. Always look at the URL; if it is not something you think is legitimate, then close that tab immediately.

3. When you connect your Metamask or other wallet, the wallet will prompt you for permissions. READ EVERY detail on the popup before clicking approve. If you don’t understand, reject. Remember that malware scripts will repeatedly ask for approval.

4. If you lost your funds, I empathize with you. However, you can take some actions, like reporting to authorities so that others don’t fall victim. The chances of recovering funds are meager.

   1. FBI IC3 Report https://www.ic3.gov/Home/ComplaintChoice

Future Proofing

1. Install https://revoke.cash/exploits chrome extension

2. https://revoke.cash/exploits - Revoke permissions and signatures for the contracts that you don’t trust

3. Improve products like Metamask, Ethereum, and a new KYC service. I have a lot of ideas for using crowdsourcing. to stop the attacks when they are small. More to come in the next post

If you would like updates and want to learn more about my ideas. Please subscribe to the blog.

Share Technology, Education and Policy (TEP) Newsletter

However, I came across this app at 1 AM in the morning, and it seemed interesting. So, I thought I would try. I paid $30 or so for it, and it said 100% money-back guarantee, etc.

It is a personal assistant. I couldn’t stop using it till 3 AM and felt the money was already paid for.

I did the following by filling in a few questions like ChatGPT, and it took care of the rest:

1. Deleted All Data Broker Data

2. Submitted Nuclear SPAM removal request with top 12 email campaign brokers

3. Added to Do Not Call List

4. Return request for Amazon that has passed the return date. It created a letter, AND IT MAILED it. Mindboggling!

5. Signup for FREE Crypto Airdrops

6. Filed unclaimed property request

7. For fun, I uploaded a doc to mail for FREE.

8. For fun, I requested an FBI profile about me.

9. For fun, I requested a credit report, even though I was getting this from other sources.

You can do much more - Online Notary, Surf free trials, beat parking tickets, sue robocalls for cash …

Use the following code to join so WE can get some FREE stuff!

https://thewhy.li/DoNotPayCode

Very thorough and easy to follow. Dumbs down tech so much that it covers the first principles that you can build upon.

You will learn about the WHY? of this technology that can help you with your job, entrepreneurship and investments!

Time worth spending! Enjoy and share this page….

MIT Blockchain and Money

This really speaks to people with high cognitive abilities that need scientific evidence for everything that they do.

This book is so needed in today’s world where 60% of the population is experiencing some form of depression from isolation and feeling lost.

Spirituality can be passed down to generations through genes (29%). 71% is in your hands (nurture). Go change yourself!

Blinkist Summary (Text/Audio) - Awakened Brain (Referral link to get discount)

Thrift Books - Awakened Brain

Please leave you comments about what you liked or didn’t like.

A very nice Reddit blog from the experience of 2018 market crash

https://www.reddit.com/r/CryptoCurrency/comments/l7ke1f/psa_for_new_dogecoin_crypto_buyers/

Buy those coins that have true business value and strong tokenomics. Check out my reading list and video play lists

Read: Crypto: Reading List - Start Here

Happy earnings and stressless life :-)

Get 30 day free trial

Here is a sample portfolio beginners. This is just a sample; I will be posting about each coin and why I am buying, the risks, how long to hold and when to exit.

Be an Investor NOT Trader: DO NOT INVEST BEFORE UNDERSTANDING about the Coin **. Learn more about the coins in each category and buy.

Watch: “TheWhyman - Crypto What?” - Playlist

Whatever the price you buy at, in the short term it probably will go down, but in the long run, you will probably will make your money based on the phase of the cycle.

Read Next: Crypto HOW: #4 - Crypto Market Dynamics

• 40% of your crypto portfolio (Low Risk)

  • BTC - 10yrs+

• 30% of your crypto portfolio (Medium Risk)

  • ETH - long term - 5yrs+ - ETH may outperform BTC

  • LINK - connects to ETH to other markets. Own it with ETH

  • FIL - Decentralized storage. Web 3.0 basics for replicating AWS

• 25% of your portfolio (High Risk) -  Watch these videos first - business value proposition

  • BAT - Get paid to view ads - Google Ads killer - 10M Brave browser users

  • POT - Faster Blockchain - So many FinTech apps

  • ADA - Faster Blockchain - ETH co-founder with 

  • RUNE - Cross blockchain Decentralized Exchange

  • LUNA - E-commerce Korea started by Stanford grads

  • THETA - Video Streaming - Youtube killer

  • LPT - Live video streaming - a very difficult thing to achieve

  • ENJ - Gaming - take you in game purchases to other games - really huge

  • AUDIO - Music audio sales - 500k customers

  • CHZ - Sports fan coins - Own you team and make decisions, not just watch

  • VRA  - Video watching proof and ads

  • GRT - 1 yr. Basis for all DeFi projects to succeed

  • Mina - a revolutionary smallest blockchain that you can run on your cell - 25kb. Will be a game changer on how we do Defi. Sathoshi Nakamoto couldn’t be more happier than this true decentralization.

  • Many More….

• 5% of your portfolio (Extremely High Risk)

My Portfolio

Here is my portfolio in realtime. Remember that I am an advanced user and I buy into many experimental projects and sometimes, I burn my hands on those as well.

https://coinstats.app/p/63OKfU

Don’t buy everything that I buy! Decide based on how advanced you are.

Your Portfolio

Beginners

Stay with BTC and ETH. Don’t venture into Alt coins, there are high chances that you will burn your hands. The only way you can get to next level is to spend more time reading about the market and understand all the dynamics. Read all the blog posts in this blog before moving to advanced.

Intermediate

Now, you can venture into Large Caps like LINK, SOL, ADA, DOT, BAT, GRT. If you want to venture further, understand all the token types and learn more about each of the tokens in details. Watch the playlist to get more in-depth knowledge and understand when to get in. Use tools like Aurox (See tools blog) to see buy/sell signals.

This is where you get into staking to earn more interest and etc. For now, you can stake in the platforms like Coinbase, Crypto.com and Kraken.

Advanced

By now, you should have metamask setup. You can now venture into tokens like, VET, AUDIUS, AXS.

This where you get into advanced staking like yearn.finance, aave and others.

Get 30 day free trial

Bitcoin And The Alts

Anything that is not a bitcoin, it is called an alternative coin. Each have their cycles.

• When BTC moves down, everything goes down

• When BTC moves up, everything else follows up

• When BTC moves sideways, traders get bored, take profits and move money to mid cap, small cap and micro cap looking for more returns.

Technically when Alt season index is >75, i.e, Alts have done way better than BTC, this is when you want to move your money to BTC. When index < 25, BTC outpaced Alts, and Alts are cheap, move to Alts.

Blockchaincenter - Check out Thewhyman.com Crypto tools for more tools like this

Money Flow

Final Thoughts

We are in Alt supercycle this year. These markets move with in days or weeks.

Pay close attention to the following if you have invested in mid and low cap.

• “TheWhyman - Crypto Trends?” - Playlist

• Follow me on twitter

• Join private Telegram channel to get updates!

See you all on the private channel!

Invest in experimental (6% max), short (20%), long term (30%) and fixed assets (40%). Allocate money appropriately. It is the $ amount across these that matters, not number of stocks etc.

How Much to Invest in Crypto?

General investing guideline is not to exceed 6% of your entire wealth into Crypto. This is considering your investments in home (equity portion only) and other real-estate as well.

If you lose, you won’t feel bad. But the returns are great 10000%.

How to Test if You Invested the Right Amount?

Investing more than you can stomach

• Are you not able to sleep at night without thinking about your investments?

• Are you checking your portfolio every few hours?

• Are you adjusting your portfolio every few weeks or less?

If you answered yes, this is a good sign that you have invested more or you haven’t invested with conviction like Warren Buffett. Here are the things you can do:

• Gain more knowledge on the things you invested in to see if you still believe those

• If you are not convinced, then transfer to other assets that are less risky but may return less.

• Final resort, exit that asset and take profits when relative strength index (RSI) is in overbought level to maximize your returns. (See my tools blog and get TradingView app and watch tools & technical analysis video playlist).

Investing Less

Just put yourself in 10yrs from now and think about the price of that asset and see if you would feel that you had invested less. Ex: Based on the current valid predictions by S2F model, BTC price in 10yrs is going to be a ridiculous $10M. (I know, if someone told you in 2009 when BTC $0.1 that it will be $60k in 10yrs, would you have believed them?)

Understand the Crypto Market & Risk Profile

Just like stocks, Crypto is also broken down into Large Cap, Mid Cap, and Small Cap. Each have different dynamics and they work in relation to the other. (Will add new positing on how they move relative to each other)

Market Cap = Total Current Coins Supply * Price

Market Cap visualization

The bigger the box, the bigger the market. Did you see that BTC is ~half of all the Crypto market and ETH is ~30% and then BNB ~10% of the entire market.

Volume and Market Cap

The bigger the market cap, the more volume it has, i.e, less volatility. Low market cap, high volatility.

Important: **** It is unlikely that none of the tokens market cap is going to exceed that of the Bitcoin in near time.

Read: Top 101 Tokens By Purpose

You need to allocate based on the cap, putting more to large cap, then a little less in mid cap, then a smaller portion in low cap, and a tiny fraction on micro cap.

Large Cap

Usually top 3 coins come under this bucket. Ex: BTC, ETH, BNB.

• Bitcoin (BTC) is an Asset - This is very unique limited supply token (scarcity principle - Read Crypto why: #1). This is seen as a hedge against deflation. Thus requires a different allocation percentage. You can HODL for a long time. Don’t trade this much and pay only long term tax by holding more than 1 yr.

• Ethereum (ETH) is a token for general purpose blockchain - This is inflationary now; with ETH2 release in summer 2021, this will become deflationary - many take over Bitcoin.

• Binance (BNB) - Trading platform token. Gets trading fees and early investments in other crypto projects.

Mid Cap

Usually top 4-20 coins that have more than a Billion market cap.

Low Cap

Anything beyond 20 and less than a Billion.

Coin Rankings: coinmarketcap.com

Micro Cap

These are new projects that you may have heard of that have a market cap of a $1M with a million token supply (price shouldn’t matter).

It can go up multifold (theoretical max of 1000,000x), i.e, not to cross Bitcoin market cap.

Hypothetically, if you invested a $1000 and it was hugely successful and went hyperbolic 1000x or (100000 %), you will end up with a Million dollars!

BTW - AAVE went up by this % in the last year.

Model Your Crypto Portfolio

Create a portfolio based on the model portfolio. Watch other successful people’s portfolios to replicate. DO NOT replicate those very popular ones like BitBoy, you will get burned; this is called pump and dump.

I had the first hand experience, once he releases a new video, a million followers will rush to buy those driving the price high; then, you end up buying high and sell it low as it will fall sharply!

Crypto: WHAT - #2 - Model Portfolio

Strong Word of Warning for the Newbies

Honest story of a trader who gambled with credit money on too good to be true projects, used robot trading and lost a lot.

Read: Not Another Fairytale Ending a Word of Warning

Summary: Don’t chase losses, don’t look for the next get rich scheme and don’t invest money that isn’t yours to start with. Basically, don’t ruin your life like me. If only I had just held.

This market is still nascent and is extremely volatile - price can fluctuate a lot. Don’t get into options and futures and use excess leverage; many traders have been wiped out with 30% drops and quick recoveries.

Don’t use credit money; no matter, how good this story is, buy with savings that you can afford to lose or experiment with.

Note to DOGE and Other Micro Cap Buyers

Don’t get carried away and buy just because others are buying

Crypto: WHAT - #3 - Note to DOGE Buyers

Final Thoughts

KISS: Keep it simple and sweet - Simple strategy for better sleep and low risk. Simply accumulate as much BTC/ETH as you can and HODL - forget about it for a few year! BTC/ETH have been returning around 160% every year; you will probably get 10x returns in 5-10 yrs.

You don’t have to put any money into mid, low cap or micro cap!

Goal: Get better sleep - what good is the money, when you can’t have mental peace?

Get 30 day free trial