TetraMesa

What “Decentralized” Really Means in Web3 Products

By

The early days of the internet were characterized by a dream that was like a philosophical stance; a “World Wide Web” with no owners that could be used by anyone. (Though infrastructure and control points still existed.) Over time, that dream turned to become a much more commercialized Web, with major portions consolidated in the hands of a few tech giants like Amazon, Google, and Facebook. Web3 was in some ways meant as a “reboot” of that original dream. A reboot powered by a single word, loaded with diverse meanings: “Decentralization”.

However, as the term has moved from whitepapers to marketing billboards, its meaning has become a bit blurred. Much of the time, decentralization is used to refer to technical aspects of elements referred to as crypto or Web3. On the general user side, many may believe that if a product involves a “token” or a “wallet” it is decentralized. This is a potentially inaccurate perception. In reality, decentralization is more like a spectrum than a binary setting. The question isn’t if an app is decentralized, but how much. And the core of such things may be technology based, but there’s other aspects that should be considered.

This post sketches a four-aspect map of decentralization that you can use to look past the branding into the actual way a product functions.

[Read more…]

Security Tokenization Oddities: Unresolved Issues Behind the Hype

By

There’s a lot of tokenization discussion in 2026 that seems flooded with hype from issuers, banks, and crypto natives. I’d like to try for some balanced realism vs. breathless promotion or vague warnings.

Ripped from the hands of early pure Crypto exuberance, tokenization is clearly the big innovation in finance right now. Early crypto may have been as much ideological as it was a maybe useful new form of finance. But at this point, the benefits and use cases for more mainstream tokenization are becoming clearer. Securities that move on digital rails could settle faster, reduce reconciliation, support fractional ownership, improve transparency, automate parts of the asset lifecycle, and create new ways to use assets as collateral, and more. What could be better?

Some industry estimates, including Fireblocks’ 2026 tokenization guide, project or report post-trade processing cost reductions of 35–65% depending on asset class, issuance cost savings of 40–50% for certain corporate bonds, faster settlement, and improved capital efficiency through programmable collateral and liquidity management. These efficiencies compound across issuance, reconciliation, and treasury operations. (Check out Fireblocks Executive’s Guide to Tokenization 2026.) As much as I’m a fan of what’s going on, among my favorite things to do is look behind the curtains, around the corners and so on. To understand and help others see what’s not always clear through the hype. And there’s a lot of hype. Though my personal favorite is collapse of settlement times. I’ve always found it interesting that something that started due to the need to reconcile physical paper strips moving around Wall St. persists even with today’s systems.

The benefits show the attractive version. And it’s all generally true enough. Still, even with recent advances, we’re early in these efforts. The deeper version is more complicated. There’s still holes in this area. The more serious tokenization becomes, the less it looks like simply “putting stocks on-chain.” (Or whatever asset we’d be talking about.) It starts looking like a full-stack rebuild of financial market infrastructure, including issuance, investor onboarding, KYC (Know Your Customer), custody, smart contracts (which are of course a new element), transfer agents, settlement assets, corporate actions, reporting, legal records, and dispute handling. And more. Those are just the big pieces.

This is progress. But it also proves the central point. The token is only one layer. And not everything is better. This is an opportunity to make things better. And yet there’s some new issues that get created here that we still have to collectively sort out. A recurring theme in recent tokenization discussions is that institutional tokenization is no longer being framed as crypto experimentation. It’s being framed as regulated, programmable financial infrastructure. This may be obvious. And it’s a good thing, (my opinion anyway), yet we need to pay closer attention than ever. While we create more efficiency, we’re going so fast we may also be creating some possibly dangerous dependencies as we string more of these tools together. (Consider my October, 2025 article on Will RWA Tokenization Growth Increase Systemic Risk? It was focused more on Real World Assets, but a lot of the ecosystem risks are similar.)

Since tokenization is becoming real financial infrastructure, this means the unresolved details matter more.

[Read more…]

Understanding Payments and x402

By

Quick History and Value

The web was built to move information quickly, but not value. A page can load in milliseconds, yet payment usually happens somewhere else: through a checkout page, account or subscription. This separation still shapes how digital access is sold. Even when the product is fully online, the payment flow often feels added on top of the web rather than built into it. That separation is finally ending. x402 turns the long-dormant HTTP 402 ‘Payment Required’ status into a native, instant payment layer, letting AI agents and apps pay per request in stablecoins without accounts, logins, or manual steps.”

x402 tries to close that gap by making payment part of the HTTP request itself. When access requires payment, a server can return payment details instead of sending the user or application into a separate billing flow. The client pays, repeats the request and receives the resource. In simple terms, x402 turns payment into part of the same request-response pattern that already powers the web.

Now for the deeper story…

[Read more…]

Can Prediction Markets Help Product Managers Make Better Bets?

By

For all the product tools we have, from customer profiles to journey maps, there’s been little use of prediction markets to inform decisions. Unlike AI-driven predictive analytics, prediction markets remain rare in product work. With generative AI pushing teams toward faster experimentation and shipping, they may be worth another look. I became interested in this while playing with a few markets myself and wondering how they might apply to product work.

[Read more…]

Part 2: Practical Tactical AI Tool Challenges: Workflow Reality, Context, and Prompting

By

In Part 1, I focused on why AI product work gets messy so quickly. Strategy theater, bad data, dependency problems, and workflow brittleness. This next section moves closer to the machinery itself: workflow tools, notebook sandboxes, exception handling, observability, skill files, context, and prompt engineering.

Workflow Operations – Langchain Type Tools

I use n8n.io for several tasks; a couple professional and several personal. If I was a real developer, maybe I’d be using something closer to pure code. But I’m not. Still, I think tools like these are more than just a crutch. And they’re certainly a fast way to wire things up for some basic testing. (Though some argue newer generative code tools are better and you can skip such things. I’ve been using both though, and find – as usual – what’s best depends on the use case.)

Regardless of platforms, the thing you really need to do with these tools is have an MLOps view from a Product perspective; either something you built yourself or in partnership with your AI/ML/Dev team members. Ideally you have a skilled architect on staff, however you should be collaborating on these things or at least in the loop. In a startup, there might be some more heavy lifting on the product side.

[Read more…]

Part 1: Practical Tactical AI Tool Challenges: Why the Work Gets Messy Fast

By

Article heading image with two businesspeople examining an AI workflow on a large screen monitor.

This three part series is not a warm, fuzzy post about some AI strategic theater, though there are both strategic and tactical issues included. It’s a walk down some paths regarding practical issues. It’s about some of the challenging practical realities we face once product people try learning about or making tools work in actual workflows. You may feel some of my personal scar tissue in some of these passages. This is for semi-technical product people working with or learning several AI tools and dealing with some of the practical gotcha’s in making them go. It’s also raising a hand and calling BS on the spew of feed drivel about how “all you have to do is just set all this stuff up and crap magically happens.”

What’s Ahead? failures, data, workflow ops, context and prompting, evals, governance and kill switches, costs, complacency, and more, mostly related to smaller or mid-sized projects; though some ideas apply to all. This is a rather long series, even for me. But when I study and do things, I tend to go deep. As is often the case, these posts are really based on my notes to myself in my personal wiki over time, cleaned up somewhat and posted here to share.

These tools are great and I really enjoy them, even if there are some challenging spots, which we’re about to explore. Some of this stuff feels magical! And fun if you have that attitude. It really can be just fun and satisfying to see a workflow executing well if you’re working hands on. However, issues can quickly become a major hassle. It’s rarely as it is in so much of the feed fawning I see. On the surface, it looks like product managers, all of us really, are being sold a fantasy of frictionless AI tooling. It makes me wonder if some of these folks are actually using these tools for real. My own experience, and interacting with others or via Reddit and so forth, shows a usually more challenging and meandering path. That’s ok. I get it. The Happy Path is easier to write about and slap together a LinkedIn post or YouTube or whatever. Unfortunately, it also obscures some likely realities.

Here’s my message as we drive through the messy parts. You’re ok. It’s not you. These things can still be a little sloppy. Just keep pushing through.

[Read more…]

AI Ethics: How Should WE Treat THEM

By

Most AI Ethics talk is about how we should manage our new tools in terms of their output and actions with regard to us. Not the other way around. I wanted to explore the other side. There’s been some thought and work in adjacent areas, and I’ll cover that. What I’m interested in considering is this… What does routine casual, dismissive behavior or even contempt toward human-like AI do to harm to our human character, habits, empathy, and social norms? Are there things we should be doing in our designs of these tools to nudge towards outcomes that don’t end up degrading our own humanity? This is about concerns regarding the potential for human self-corruption, not machine victimhood. Most AI ethics asks how AI should treat us. I want to ask what our treatment of AI may be doing to us from an ethics and morals perspective, not just general cognitive issues.

[Read more…]

Bad Customer Service? Or Market Opportunity

By

One Family, One Month, Multiple Customer Service Failures. Many Insights.

Over one month, our family logged bad customer service experiences. Not quite a formal study, but we did it because the same kinds of friction kept showing up. We’re both marketers, one in digital product, the other a corporate brand manager. So we analyze things. For example, when we go to a store, it’s not just shopping, it’s consumer ethnography. Like anyone facing typical consumer issues, we usually just power through minor annoyances and move on. But then thought “For one month, let’s pay closer attention and see what happens?”

[Read more…]

BEO – Bot Engine Optimization

By

Most people discussing agent optimization are talking about basic visibility or commerce mechanics. I’d like to go deeper: data structures, trust, identity, interoperability, and security. I’m not sorry about trying to coin the term BEO. Except, as it turns out after a search, I’m maybe a month or so from not being first with this, (so close!). Though I’d like to extend the concept anyway, based on my own experience building and what I’ve been seeing.

We shouldn’t use AEO, for “agent”, because that’s taken. We need something new because as we all know if there’s no acronym, it really can’t be a technology. And wouldn’t it be nice to have unambiguous names? I mean, “DaaS” can apparently be “Data as a Service” or “Desktop as a Service” and we have plenty of other ambiguous mess. We should try to do better with our naming. Why Bot Engines now? We’ve trudged through the cave-dwelling ancient history of Search Engine Optimization (SEO), evolved into Answer Engine Optimization (AEO), and now we’re managing Generative Engine Optimization (GEO). So, naturally, we need something fresh. I’d like to try out BEO for the win as an idea. It’s the art and science of tuning bots, agents, and autonomous systems to thrive in interconnected digital ecosystems; optimizing them not just for performance, but for discoverability, interoperability, and trustworthiness in a world where machines negotiate, transact, and collaborate on our behalf.

It’s SEO, (though much more), for the agentic era. Just as websites compete for search visibility, bots will need to stand out in marketplaces, integrate with protocols, and build reputations.

[Read more…]

Location

We're located in Stamford, CT, "The City that Works." Most of our in person engagement Clients are located in the metro NYC area in either New York City, Westchester or Fairfield Counties, as well as Los Angeles and San Francisco. We do off site work for a variety of Clients as well.

Have a Project?

If you have a project you would like to discuss, just get in touch via our Contact Form.

Connect

As a small consultancy, we spend more time with our Clients' social media than our own. If you would like to keep up with us the rare times we have something important enough to say via social media, feel free to follow our accounts.