CPVRD

Dispatches.

B2A vs B2A2C

A checkout form filled in by an agent — name "agent-7f3a", card number "whose?", and an unchecked "I'm not a robot" box.

After I left Nubank, I started a few things: writing, advisory and building again, to truly learn GenAI as an engineer instead of an executive.

In one of my pet projects, I have agents building ML models that forecast the NFL season based on real data from many different sources, to learn how to tame them for that type of work.

Often enough, my agents got stuck with the lack of available data to improve the model. As they wanted to get unblocked, they asked me to “just buy it” so we keep moving.

I often held them back. But when they got really stuck, I went and bought some of these precious API keys myself so work could continue.

Why did I as a human have to enter a website and put my credit card info? The agents seemed to know what they needed, but had no way to pay for it.

I don’t even know if I trust them with a card, but I also didn’t trust them to code for me a couple months ago.

Companies are starting to think about selling to agents, but mostly the shopping kind: an agent buying on behalf of a person, which is what I call B2A2C. It books a flight, fills the cart, buys food, etc.

The human-first assumptions survive there, because there is a human at the end of that chain with goals, a wallet and taste.

The untapped opportunity is the building kind: products where the agent is the end user, no human waiting at the end of the chain. Think of things that your agents get stuck on: data, access, insights, inference from other models, conviction, taste.

Maybe even some human judgement by the minute? That might be part of the next wave of the gig economy. But more on that on another post.

Making the real B2A concrete at a high level: AEO is emerging alongside SEO, then vibe coding tools get their own wallets tokenizing payments, then companies start selling products for agents as end users, with a bunch of new tech-nerdy plumbing underneath.

One level deeper, take how the purchase is currently done: the agent gets an API key, a shared password that never expires and usually proves nothing about who authorized what. Very little supervision for a fast-moving world where output is what agents optimize for.

What I am thinking instead is a combination similar to mTLS plus tokens: a certificate authority who manages trust and the budget, certificates for each agent issued when they spin up, and short-term permission tokens for authorization.

Similar movements will be done in other areas. Payments already went through this once: card numbers became tokens, and holding the string stopped being the same as holding the authority.

And the pricing moves as the business model evolves: the real B2A looks more like marginal pricing than upfront with a high-floor, very similar to what the cloud did for computing. That one deserves its own post too.

Founders and VCs are thinking hard about the protocol the agent uses to pay. The more interesting question is what agents will be paying for and how they earn the trust to do so.

For now, agents know all about the price of something, but have a hard time understanding its value.

Zero-Based Doctrine

A terminal showing git log over a doctrine/ directory — agile, cloud, devops, microservices, dora, remote and genai, every commit authored by "someone-else", 2001 to 2025 — a clean working tree, then a git rm --cached command half-typed, waiting.

In 1969 an accountant at Texas Instruments went looking for waste and found something worse: inertia deciding how the company ran. Peter Pyhrr’s fix was zero-based budgeting. Every cycle, the budget starts from zero and every expense earns its way back in, whatever last year said.

For everything beyond money, the answer is usually incremental evolution, but a deeper review is required when the playing field tilts.

Right now, many companies are looking at the AI transformation and have started a series of process improvements. But what about the company’s set of beliefs, goals, working agreements, and everything else that originates the processes?

The systems thinker Donella Meadows would call that layer the paradigm, the deepest practical place to intervene in a system, and I endorse intervening in a more grounded manner: give it the Pyhrr treatment.

How did the Agile Manifesto come to be? Seventeen practitioners met at a ski lodge in Utah after spending years inside real companies running lightweight methods that worked, under different names. Over a weekend, they uncovered and distilled the principles they were already living and wrote them down. Extracted from practice, backed by the trenches: the foundational stone of a new doctrine.

There was no improving waterfall into agile. Better DevOps is still DevOps. Some companies are AI-adopters, some are AI-first and some are AI-native. Huge difference.

Every few months a step change in the models resets what the tools can do, and the tools reset the ways of working built on top of them. Until that settles, nobody can claim a best practice as lasting. The next manifesto comes later, extracted from practice like the first one.

So what can you do before the puck stops moving?

Lead with vision. Read the movement. The next moves do not need the destination.

For larger organizations, identifying the areas most likely to change is already progress. Starting the evolution, moving from “run the bank” to “change the bank”, is progress too, and definitely not enough.

And this is the whole point: audit your own doctrine, one premise at a time. Starting clean, with the tools that exist today, would we still choose this? Some premises will survive. A few will turn out to be last decade’s budget, renewed every year without a conscious decision being made by anybody.

I have my own set of bold predictions that I am keeping warm for a future post. For now, the work is simpler: understand your practices, when each was last chosen, and why. That awareness is what gives you the right to change the paradigm instead of being trapped inside it.

Wrong, Faster

Renan holding a mug that reads "You're Absolutely Right!", wearing the matching shirt, next to the line "How long does it take you to find out you're not?

Almost every new AI founder believes their edge is that they ship fast. So do a lot of the incumbents racing to match them.

A cycle ago they’d have been right, back when speed was an advantage and not yet a requirement.

Being fast still beats a slow incumbent. It doesn’t separate you from the twenty teams in your cohort, all running the same models you are, telling their investors exactly what you’re telling yours.

AI made building fast, so most teams use it to do more: more code, more launches, greener productivity dashboards, and a lot of it the customer never feels.

AI makes you fast, and worse, confident. Hand it a bad premise and it’ll build a cathedral on top of it, coherent all the way up and wrong at the foundation. The real danger is how long you build before you find out you were wrong. None of that is new. Russell Ackoff called it “doing the wrong thing righter.” AI just gets you there faster, and makes the wrong thing look more convincing on the way.

So if speed isn’t the edge, what is? I spent a decade inside one of the fastest-growing companies anyone has built. Speed was never our problem. It also wasn’t what made us hard to beat.

The moat was doctrine, and not the kind that lives on a slide deck. I mean how a company builds and decides, all the way down. Agile, DevOps, continuous delivery, cloud-native were each a version of it, the best anyone knew for the tech and the problems of the moment.

Capital and distribution are usually the incumbent’s edge, not the newcomer’s. Doctrine is how you take it from them. Build the right way and you out-execute long enough to win your own, while the incumbent can’t copy the method cheaply. Doctrine isn’t a feature you install. It’s the whole org. You pay for it once while you’re small, or you pay forever fighting your own antibodies.

But every doctrine is built for a world, and the world keeps moving. The old one is expiring, and the next can’t be written until the tech settles for a couple of cycles.

So the moat moved up a level. You still need a doctrine. Going without one is just chaos with good PR. But the right doctrine keeps changing, so owning today’s isn’t the prize. The edge is how fast you can tell yours has gone wrong, and write the next one before the world writes it for you.

That’s the rare thing a competitor can’t copy by deciding to, because it isn’t a practice. It’s a temperament. Truth-seeking, even when the truth is that you’re wrong.

Whether you’re building one or betting on one, the next time a founder shows you how fast they ship, ask a better question. When you’re wrong, how long does it take you to find out?