2026-04-16 17:46:34
Stablecoins have moved from crypto native curiosity to serious financial infrastructure and nowhere is that shift more consequential than Asia, where dollar-denominated settlement sits at the intersection of regulatory complexity, booming Web3 adoption, and chronically underserved developer tooling.
\ Stables is betting it can own that infrastructure layer. I sat down with Bernardo Bilotta, Co-founder and CEO of Stables, to understand what they're building, why Asia, and whether the "Stripe for stablecoins" label actually fits.
\ Ishan Pandey: Hi Bernardo, welcome to our "Behind the Startup" series. Tell us about yourself and what led you to build Stables?
\ Bernardo Bilotta: We started Stables in 2021 because the stablecoin experience for consumers was terrible. I've spent the previous decade building fintech consumer products, including leading the global rollout of the Zip app to more than 10 million users as Head of Mobile at Zip Co. That background gave me a very clear understanding of what consumer-grade financial products look like, and stablecoin wallets and experiences in 2021 were nowhere close.
\ Hundreds of millions of people across Asia and emerging markets were already using USDT as their de facto digital dollar. But the products they were using looked and felt like they'd been built by and for crypto engineers. The wallets were clunky, the flows were confusing, and the entire experience assumed you already understood blockchain. We set out to build the best consumer stablecoin product in the market, something that felt like a proper neobank, not a crypto tool.
\ The problem was that there was nothing to build on. No off-the-shelf infrastructure for stablecoin payments existed, certainly not in Asia. No compliant on-ramp and off-ramp APIs. No unified compliance stack. No reliable corridors between USDT and local currencies. So to build the consumer experience we wanted, we had to build all of the infrastructure underneath it ourselves: the banking integrations, the KYC and AML pipelines, the transaction monitoring, the liquidity connections, the fiat settlement rails. Every layer, from scratch.
\ My co-founders brought the right pieces to make that possible. Daniel Li had built Readii to over $20 million in ARR and understood how to scale commercial operations. David Nichols is a lawyer with 20 years in banking risk and compliance, including co-founding Xinja Bank and leading risk at Commonwealth Bank of Australia. Between the three of us, we had the product instinct, the commercial engine, and the regulatory backbone to actually pull it off.
\ What we didn't anticipate was that the infrastructure we built to power our own product would turn out to be more valuable than the product itself. That realization came later, and it changed everything about our trajectory. But the founding impulse was simple: stablecoins deserved a consumer experience as good as the best neobanks in the world, and nobody was building it.
\ Ishan Pandey: Stables launched in 2021 as a stablecoin neobank. What changed internally, in the market or in your own thinking, that led you to open up your infrastructure to developers as a B2B API platform?
\ Bernardo Bilotta: We built the consumer wallet first because we needed to. There was no off-the-shelf infrastructure for stablecoin neobanking in 2021, certainly not in Asia. So we built everything ourselves: the compliance stack, the banking integrations, the on-ramp and off-ramp corridors, the KYC flows, the transaction monitoring. All of it, from the ground up.
\ What changed was the realisation that the hardest part of what we'd built wasn't the wallet interface. It was the infrastructure underneath it. And every other company trying to build on stablecoin rails in the region was hitting the same wall we'd already climbed over: fragmented banking relationships, jurisdiction-by-jurisdiction compliance, unreliable liquidity, and months of engineering just to get a single corridor live.
\ The pivot wasn't a pivot in the dramatic sense. It was more like looking at what we'd built and recognising that the infrastructure was the product. The wallet was a proof of concept; the rails were the business. Once we opened those APIs to other developers, volume grew 8x in a matter of months. That told us everything we needed to know.
\ The market timing helped too. By 2025, regulatory clarity was arriving across key jurisdictions, institutional capital was starting to take stablecoins seriously, and developer demand for compliant, programmable rails had outpaced what any single provider could offer. We'd already built the thing everyone else was scrambling to piece together.
\ Ishan Pandey: You're specifically focused on building compliant USDT rails for the Asian Web3 market. Asia is the largest remittance recipient region in the world, yet you've said the stablecoin infrastructure there remains deeply fragmented. What structural problem are you solving that existing players have failed to address?
\ Bernardo Bilotta: The numbers tell the story pretty clearly. Only about 1% of local banks in Asia are willing to work closely with stablecoin businesses. There are roughly 150 currencies in the region that need stablecoin connectivity. And as of our last analysis, there were zero licensed orchestration platforms purpose-built for USDT in Asia. Zero.
\ That's the structural problem. Asia drives approximately 60% of global stablecoin payment flows, yet there's been a massive overinvestment in the US and Latin America when it comes to stablecoin infrastructure. The capital and the builder attention went west, and the region generating the most actual payment volume got left with duct tape and manual processes.
\ What existing players have failed to address is the full-stack problem. You've got on-ramp providers who are consumer-focused and not built for B2B developer infrastructure. You've got regional OTC desks that are manual and not API-first. You've got crypto payment processors optimised for different stablecoin ecosystems. None of them give a developer a single integration to move USDT in and out of local currencies across the region, with the compliance stack handled.
\ And the fragmentation compounds. Banks in Asia change their risk appetite with little warning, which means developers are constantly scrambling for alternatives. Every corridor is its own regulatory environment with its own capital controls. The result is that building a stablecoin payment product in Asia today feels like assembling a puzzle where the pieces keep changing shape. We built Stables to be the table the puzzle sits on.
\ Ishan Pandey: You've described what you call the "corridor trap", where every new payment corridor requires a new banking relationship, a new compliance stack, and a new integration timeline. How does Stables' infrastructure break that cycle technically, and how does it handle regulatory compliance without adding friction at the developer layer?
\ Bernardo Bilotta: The corridor trap is real, and it's the single biggest reason stablecoin businesses in Asia grow slowly. Without us, every new corridor means a new banking partner to negotiate with, a new compliance framework to build, a new integration to engineer and maintain. It's not a software problem. It's a business development and regulatory problem that happens to require software to solve.
\ Our API is built on three pillars. The Customer layer handles identity, compliance, and risk: KYC and KYB verification, real-time transaction monitoring and KYT, sanctions screening, and travel rule compliance for cross-border transactions. The Ledger layer handles reconciliation and auditability, tracking every debit, credit, and stablecoin-to-fiat conversion with a clean audit trail. The Transfer layer handles orchestration across both fiat and stablecoin rails, including virtual accounts, banking rails, on-chain settlement, and deep stablecoin-to-fiat liquidity.
\ For the developer, all three layers sit behind a single integration. They submit their end users via API. We handle the KYC, the compliance screening, the transaction monitoring. Their users can on-ramp from local currency to USDT or off-ramp from USDT to local currency in their bank account. New corridors become a configuration change, not an engineering project.
\ On the compliance side, we're multi-jurisdictionally licensed. We hold licences in Australia, Europe, and Canada today, with licensing in progress in the UAE and Singapore. Our structure allows us to expand into new jurisdictions by issuing products through existing licensed entities under unified global compliance policies. That means a developer integrating once gets access to our entire licensed corridor network without having to think about regulatory fragmentation.
\ The friction reduction is the product. If a developer has to spend engineering months integrating fragile banking partners, or if frozen funds and failed payouts are eroding their margins, or if compliance delays are damaging their end users' experience, then the infrastructure has failed. Our job is to make all of that invisible.
\ Ishan Pandey: You've processed over a billion dollars in retail transactions and support payments across 19 blockchain networks. Most stablecoin conversations focus on picking the right chain. You've argued that's the wrong question entirely. What should enterprises actually be asking when they build a stablecoin strategy?
\ Bernardo Bilotta: The chain question is a distraction. It's like asking which highway your delivery truck should use when the real question is whether the goods arrive on time, at the right cost, in a way the customer trusts. Enterprises get pulled into chain debates because that's where the marketing noise is. But the problems that actually kill stablecoin adoption in a business context have nothing to do with which L1 or L2 you settle on.
\ The questions enterprises should be asking are more fundamental. Can I move USDT into and out of the local currencies my customers use, reliably, at scale? Can I do it without building a compliance stack in every jurisdiction I operate in? Can I add a new corridor without a six-month integration project? What happens to my funds when a banking partner changes their risk appetite overnight?
\ This is exactly why our integration with USDT0 and LayerZero matters. USDT0 is Tether's omnichain standard, which means USDT can move natively across supported chains without the developer managing bridge infrastructure or multi-chain complexity. For our developers, USDT just moves. They don't need to think about which chain it lives on, because the orchestration layer handles that.
\ The enterprises that will win in stablecoin payments are the ones who stop optimising for chain selection and start optimising for corridor coverage, compliance reliability, and settlement speed. Those are the variables that determine whether a payment product works for real users or just looks good in a pitch deck.
\ Ishan Pandey: Stables has partnerships with Mastercard, Circle, Marqeta, and Coins.ph, and is now expanding into the UAE through Hub71. How do you see this infrastructure contributing to the broader convergence of traditional finance and blockchain-based capital markets — particularly in markets where only around 1% of local banks are willing to work with stablecoins?
\ Bernardo Bilotta: The convergence is already happening, and it's happening faster than most people in traditional finance realise. The question isn't whether fiat and stablecoin rails will merge. It's who builds the connective tissue between them.
\ Our partnership ecosystem reflects that conviction. We've built relationships across both traditional payment networks and the stablecoin-native ecosystem because the infrastructure needs to bridge both worlds. The UAE expansion through Hub71 is strategic. The Middle East is moving faster than almost any other region on regulatory clarity for digital assets, and Dubai in particular is becoming a hub for stablecoin infrastructure companies. That aligns with where we need to be as we scale our corridor coverage beyond Asia into the broader emerging market ecosystem.
\ As for the 1% banking problem, that's actually a competitive advantage for us rather than a barrier. Because so few banks are willing to work with stablecoins, the companies that have already built those banking relationships and wrapped them in a compliant, developer-friendly API have a moat that's extremely hard to replicate. Every banking relationship we hold is one that took months of trust-building to establish. A new entrant can't just spin that up.
\ Ishan Pandey: Given that USDT dominates stablecoin volumes in Asia, your platform seems naturally positioned to serve as connective tissue across Tether-based services in the region. Is unifying that ecosystem a deliberate strategic goal, or an organic outcome of what you're building?
\ Bernardo Bilotta: Deliberate. Completely deliberate.
We are USDT-native by design, not by default. Every partnership in our stack is USDT-aligned. Our integration with USDT0 and LayerZero. Our liquidity partnerships with Mansa and t0 Network. Our institutional rails partnership with eStable, which includes local stablecoin issuing backed by USDT and Hadron. The entire architecture is built around the stablecoin that actually dominates payment flows in Asia.
\ USDT isn't just the most popular stablecoin in the region. It's a $35 trillion payment network. Think of it as a global dollar highway. What Asia has been missing is the on-ramps and off-ramps that connect that highway to local economies in a compliant, programmable way. That's what we're building.
\ We have an active collaboration with Tether that gives us unmatched access to Tether's banking network, liquidity depth, and market credibility. That relationship isn't something we stumbled into. We pursued it because being deeply embedded in the Tether ecosystem is the single most important strategic position you can hold if you're building stablecoin infrastructure in Asia.
\ The way I think about it: in every major technology platform shift, the companies that align early and deeply with the dominant ecosystem capture disproportionate value. USDT is the dominant ecosystem in Asian stablecoin payments. We're building the infrastructure layer for that ecosystem. That's not accidental.
\ Ishan Pandey: Stables has been described as "the Stripe for stablecoins in Asia." Is that analogy accurate and what does it get right or wrong about what you're actually building?
\ Bernardo Bilotta: The analogy is useful shorthand, and it captures the developer experience we're going for. Stripe made it so any developer could accept payments with a few lines of code, and the entire complexity of payment processing, fraud detection, and compliance disappeared behind a clean API. That's exactly what we're doing for stablecoin payments in Asia. One integration. Full compliance stack handled. Deep liquidity. New corridors via configuration.
\ Where the analogy falls short is in the complexity of what we're actually orchestrating underneath. Stripe built on top of existing card networks and banking infrastructure that, for all its flaws, had been standardised over decades. We're building at the intersection of two financial systems that are still learning to talk to each other: traditional banking and stablecoin rails. We're not just processing payments. We're bridging fiat and stablecoin worlds, managing multi-jurisdictional compliance, maintaining deep liquidity across volatile FX pairs, and navigating banking relationships in a region where banks can change their stablecoin risk appetite overnight.
\ The other thing the Stripe comparison misses is the specific bet we're making. Stripe is payment infrastructure. We're money movement infrastructure. The underlying thesis is that cross-border flows, which are $850 billion globally to low- and middle-income countries, are migrating from legacy rails to USDT. The serviceable addressable market for USDT-addressable flows is growing at 19% CAGR and projected to reach $340 billion by 2030. The companies that own the orchestration layer for that migration will capture disproportionate value as the market scales from millions to billions of users.
\ So yes, we're the Stripe for stablecoins in Asia in terms of the developer simplicity we deliver. But the market we're going after and the infrastructure we're building underneath is a fundamentally different animal. We're processing over $1.3 billion in annualised TPV today, we're EBITDA positive, and we're growing at 466% year over year. The Stripe analogy is a starting point for understanding what we do. The numbers tell you how big this is becoming.
\ Don’t forget to like and share the story!
\ \ \n \n
\
2026-04-16 17:01:01
Generative AI is extremely appealing for non-technical users, who feel like they've gained access to magic powers. But as this story shows, a little knowledge is a dangerous thing.
Once upon a time, there was a Chief Data Officer who believed that the new wave of Generative AI, such as ChatGPT and Gemini, could bridge any technical hurdle. At a local AI meetup, they met a founder with no technical background who had proudly built an entire prototype website using nothing but natural language prompts. It seemed like a genie in a bottle. Rub it a little bit (give it tokens), make a wish (give your prompt), and *poof* you have code, text, or some description of what you need to do.
Every day, back in their own enterprise, this data leader watched as more team members treated these general-purpose tools as magical little helpers. However, as a data expert, the CDO began to worry about the "fuzziness" of the results. Unlike the Predictive AI they were used to—which is deterministic, consistent, and built on specific statistical mathematics—Generative AI was proving to be non-deterministic. If you gave it the same prompt twice, you’d get two different answers, making it a liability for rigorous production environments.
But then one day, the genie was asked to build a web site. It did so, but did not build all the infrastructure necessary to support a web site. The CDO realized that a little knowledge is a dangerous thing. While the Generative AI could only build a beautiful facade, it couldn't account for what the user "didn't know they didn't know."
As in days of old, the “it works on my machine” dragon was waking up. The user that wrote the prompt was solely responsible for judging the accuracy of output they didn't fully understand. The person making the wish (giving the prompt) would have had to have the expertise of a software engineer, the experience of a network engineer, and the judgement of a systems engineer to get the prompt just right and know if what was generated was ultimately the right thing.
As the data team scrambled to clean up the mess, the CDO thought, “maybe this GenAI isn’t so helpful after all.”
Because of that, the CDO began looking for a better way to manage cognitive load. General Purpose Generative AI (GPGenAI) is truly a genie in a bottle: it can be a powerful but unpredictable tool to those without the right vocabulary. They needed the AI to act less like a creative writer and more like a Subject Matter Expert (SME) that could produce reliable, stable, and consistent output.
That’s what a Domain-Specific Generative AI (DSGenAI) does. DSGenAI tools are highly specialized, with embedded capabilities for tasks, such as SQL generation within known data structures or Python-specific environment management.
Because of that, the organization moved away from relying on "general" generative AI for technical tasks. They recognized that for a tool to be useful in a professional data environment, it needed to be familiar with the specific packages and data architectures of the business. DSGenAI was like a genie that has grown up in a culture of hacking SQL, munging Python, and dealing with package management hell.
Finally, the CDO established a new framework for AI adoption. They now knew that while GPGenAI is excellent for MVPs and brainstorming, production-grade data operations require the precision of DSGenAI. They stopped asking if the AI was "smart" and started asking the people using the tools if the tool was "grounded" in their specific domain.
And ever since, the data team has acted as the ultimate judge of quality. They learned that even with the best DSGenAI, the user is still responsible for verifying that the generated code matches the request. By choosing tools designed for their specific vocabulary, like METIS from DataOps.Live and CoCo (Cortex Code) from Snowflake, they reduced the risk of "non-positive consequences" and ensured that their production environment was built on a foundation of expertise, not just probability.
2026-04-16 17:00:54
When OpenAI’s list of its top 30 customers by token consumption surfaced across social channels, the immediate reaction focused on who appeared on the list. But the more important insight came from the pattern: a mix of large, mature enterprises and fast-moving AI-native startups all consuming tokens at similar scales.
This wasn’t a leaderboard of experimentation. It was a snapshot of where cognition-heavy work is already being automated—and where AI has quietly become embedded infrastructure.
It’s also important to understand what this list does not capture. OpenAI token consumption represents only one slice of how leading organizations actually run AI in production. Many of the most sophisticated teams don’t concentrate usage in a single model or provider—they distribute workloads across multiple models and vendors based on cost, latency, context length, and task complexity. In that sense, this moment mirrors the early days of cloud adoption: the companies that extracted the most leverage weren’t the ones that picked a single hyperscaler, but the ones that designed systems flexible enough to evolve as infrastructure choices changed.
Even with that limitation, the list still reveals something essential. Across this group, token consumption correlates less with company size and more with how deeply AI is woven into real workflows. The organizations driving higher consumption are using AI to replace manual reasoning, not just accelerate isolated tasks.
That signals a deeper shift. Teams are beginning to measure leverage not by headcount, but by how much cognitive work can be offloaded to AI systems. The real competitive advantage comes from designing work so AI agents can operate as specialists—not simply as assistants.
Each of the top token consumers has different motivations and use cases. AI has become embedded inside real workflows that move organizations forward: the workflows that require reasoning, decisions, and customer-facing impact. That’s why it helps to break the pattern down by sector and by role to see where this shift is actually happening.
The list revealed how broadly AI has already moved into production. Each sector uses large volumes of tokens for a different category of cognitive work:
These workflows don’t look the same, but they share something important: they represent high-cost cognitive tasks that used to be bottlenecked by human attention, not compute.
Token-heavy workloads map directly to these categories—retrieval, reasoning, summarization, mediation, debugging—because each requires deep contextual understanding at scale.
The cross-industry spread is only half the story. Inside companies, the roles that consume tokens are just as revealing:
Across these roles, the same shift is visible: AI is no longer a layer on top of work; it is an operational backbone inside the work.
This diversity isn’t noise—it’s a clear signal. The organizations consuming the most tokens are delegating meaningful cognitive work to AI systems thousands of times per day, across functions and across the stack.
A closer look at the top token consumers reveals something more interesting than a startup-versus-enterprise divide.
What’s actually happening is a structural leveling of the playing field.
Generative AI is doing for software what cloud infrastructure did a decade ago: removing a category of constraint that once favored incumbents. Just as startups no longer needed to build their own data centers to compete, they no longer need massive teams of specialists to reason across complex systems, analyze failures, or iterate quickly on customer feedback.
The result is not simply faster execution—it’s a shift in who gets to compete.
New entrants can now operate with the same cognitive surface area as much larger organizations, because AI absorbs the work that used to require scale: context gathering, cross-system reasoning, analysis, and synthesis. Tokens, in this sense, are not about “who runs more AI,” but about how much cognitive terrain a team can cover.
AI-native startups aren’t just doing existing work faster. They’re questioning whether the work needs to look the same at all.
Because AI sits at the center of their architecture from day one, these teams aren’t constrained by legacy assumptions about how problems are solved. They’re free to reimagine entire workflows—not by building a better version of the same process, but by designing fundamentally different ones.
In practice, this means:
This is why small teams can now rival the output and impact of much larger organizations. It’s not that AI has “replaced” humans—it’s that AI has removed the historical penalties of being small.
High token consumption in these teams is a byproduct of this shift. It reflects constant exploration, reasoning, and iteration embedded directly into product and engineering processes.
Key takeaway: AI-native startups gain advantage not by automating humans out of the loop, but by escaping the constraints of how work used to be done.
Enterprises approach AI from a different starting point. They carry existing systems, processes, and organizational structures that can’t be rewritten overnight.
As a result, most enterprise AI adoption today focuses on augmentation:
This isn’t a limitation—it’s a strategic reality.
Augmentation allows enterprises to unlock meaningful gains without destabilizing core systems. And when done well, it enables teams to operate at a scale and level of complexity that would otherwise be unmanageable.
Where enterprises risk falling behind is not in how much AI they use, but in whether they treat AI as a surface-level efficiency tool or as a way to fundamentally expand what their teams can reason about and act on.
Key takeaway: The competitive gap isn’t between startups and enterprises—it’s between teams that use AI to rethink how problems are solved and those that use it only to optimize existing workflows.
Seen through this lens, token consumption is not a proxy for “AI taking over work.”
It’s a signal of how much cognitive work an organization is able to engage with—how many scenarios it can explore, how much context it can reason over, and how quickly it can adapt.
That’s why tokens per employee matter more than raw volume. It reflects how much leverage each person has, not how automated the organization is.
The real transformation isn’t AI execution versus human execution. It’s constraint removal versus constraint preservation—and that’s the shift reshaping competition across software today.
The leaderboard serves a useful purpose: it shows which companies are running the most AI workloads. But total token consumption alone doesn’t tell you whether that usage is valuable, efficient, or strategically sound. A company can burn millions of tokens without changing how it operates—or deploy billions in a way that fundamentally reshapes how work gets done.
For engineering leaders, the more revealing question isn’t how many tokens the organization consumes. It’s how effectively tokens amplify human judgment and execution. The goal isn’t to replace people with AI, but to increase how much meaningful work each person can responsibly orchestrate through AI systems. That’s where durable outcomes show up: lower MTTR, more stable releases, faster iteration, and better customer experiences without linear headcount growth.
Tokens aren’t abstract units—they’re the atomic measure of machine-executed cognition. Each token represents a small unit of reasoning, retrieval, synthesis, comparison, or decision-making performed by AI for humans.
In practice, token-heavy workflows map to work that was historically expensive and slow:
When these workflows are well-architected, token consumption correlates more closely with delivered value than with raw activity. The system isn’t “thinking more” for its own sake—it’s removing cognitive bottlenecks that previously constrained teams. This shows up as shorter delivery cycles, smoother handoffs, and fewer delays caused by manual context gathering or analysis.
Total token consumption tells you how much work the system is doing. Tokens per employee reveal how work is distributed between humans and AI—and whether that balance is healthy.
More tokens per employee aren’t always better. Too few, and teams remain constrained by human bandwidth: decisions pile up, context is fragmented, and progress slows. Too many, and organizations risk letting AI make decisions without sufficient human oversight, increasing the chance of subtle errors, misalignment, or downstream risk.
The most effective teams operate in a sweet spot of AI–human leverage:
This is why tokens per employee is a better diagnostic metric than raw token volume. It reflects whether AI is being used to responsibly amplify human capability—not just automating for automation’s sake.
At that balance point, teams consistently see:
This dynamic is what drives what we refer to as the great flattening: smaller teams achieving impact that previously required far larger organizations—not because AI replaced people, but because it absorbed the most cognitively expensive parts of the workflow.
Viewing tokens through the lens of leverage rather than cost gives leaders a more straightforward way to assess AI maturity. The organizations seeing the strongest returns aren’t optimizing for token minimization or maximization—they’re optimizing for effective AI–human collaboration.
When that balance is right, improvements compound: customer-facing issues are resolved faster, releases stabilize, and teams gain confidence to move quickly without increasing operational risk. These outcomes create a direct line between AI adoption and business performance—and give leaders a practical benchmark to evaluate progress over time.
Tokens aren’t the price of experimentation. They’re the operating fuel of a new way of working—one where leverage comes from how intelligently AI and humans share the cognitive load.
Once AI stops being an experiment and becomes a core executor of work, the entire engineering system comes under pressure in ways that traditional scaling models never predicted.
AI-generated changes move faster than human review cycles. Agentic workflows introduce new dependencies and edge cases. And the pace of iteration increases not because teams grow, but because each engineer now orchestrates 10–100× more cognitive work through AI.
In other words: the moment AI starts running real production workflows, the old assumptions about pace, QA, and reliability break.
The challenges listed below are what companies at the high end of token consumption are currently facing.
When AI-driven code changes, experiments, and decisions continuously flow into production, familiar problems surface much earlier than they used to. Rapid iteration creates failure modes that previously only appeared at massive scale:
Issues that once required huge user bases or massive traffic now appear even in small teams—because throughput is no longer tied to headcount. AI accelerates delivery beyond what legacy QA, review cycles, and guardrails were designed to handle.
As soon as agents begin owning end-to-end tasks, they depend on accurate, current system context to reason correctly. When that context is incomplete or static:
Agents behave differently from humans—they don’t “work around” missing context or ambiguity. That means gaps in system understanding surface as reliability issues almost immediately.
Most QA, triage, and debugging workflows were built for human-driven change velocity, not autonomous or semi-autonomous systems. As AI-generated updates increase:
These bottlenecks aren’t a sign of poor engineering—they’re a sign that the environment has changed. AI-native velocity exposes weaknesses in traditional toolchains and processes far earlier than expected.
These challenges are not edge cases—they are structural outcomes of AI taking on real cognitive work in production. The companies consuming the most tokens are simply encountering them first—and showing that mature AI adoption demands new infrastructure, practices, and ways of working.
As AI moves into the critical path of core workflows, the companies consuming the most tokens are discovering a painful truth: traditional observability and QA aren’t built for continuous machine reasoning. Engineering teams must shift from “debugging code occasionally” to engineering reliability for nonstop, autonomous decision-making. These capabilities are the foundations required to operate AI at scale without sacrificing stability.
AI-driven systems need a complete, code-grounded view of how software behaves in production—a single model that connects repos, telemetry, user sessions, tickets, and logs.
When analysis is anchored directly in the codebase, AI can reason accurately about failures, dependencies, and user impact—eliminating hallucinated conclusions and accelerating triage dramatically.
With AI-generated changes flowing constantly, reactive reliability is no longer enough. Proactive safeguards such as automated regression detection, high-risk change identification, and early-impact signals before users feel degradation.
This shifts engineering from discovering issues late to preventing them early—critical when iteration speed outpaces human review cycles.
As workflows become more distributed and agent-driven, knowledge can no longer live in the heads of senior engineers. Auto-generated architecture maps, cross-service dependency insights, and self-service debugging context remove the dependency on institutional knowledge. This also enables junior engineers to resolve complex issues without constant escalation.
Continuous AI-led change introduces failure patterns that old debugging workflows can’t absorb. Modern reliability loops require code‑anchored evidence, centralized cross‑system context, reduced tool fragmentation, faster root‑cause analysis, and fewer repeat regressions.
Together, these create a feedback system that adapts to the velocity of AI, not the velocity of human-driven development.
For leaders, the lesson from the top token consumers isn’t “use more AI.” It’s that leverage comes from how work is structured—and how responsibility is shared between humans and AI over time.
The organizations getting outsized returns don’t flip a switch and hand everything to agents on day one. They start with humans firmly in the loop, use AI to absorb the heaviest cognitive load, and then deliberately reduce human intervention as workflows prove reliable, explainable, and repeatable. Everything else—lower MTTR, faster releases, fewer regressions—flows from that progression.
Across these organizations, a few patterns show up consistently.
High-leverage teams don’t treat AI as a sidecar or a magic replacement. They design workflows where:
Over time, agents move from assisting on isolated steps to owning larger portions of the workflow—but only once outputs are trustworthy and failure modes are well understood. This is how AI becomes an executor safely, not recklessly.
The most effective teams measure progress by outcomes, not novelty. Early on, humans remain deeply involved while teams track whether AI is actually creating leverage:
As AI systems demonstrate consistency, teams intentionally reduce manual touchpoints—freeing humans to focus on higher-order decisions instead of routine analysis. Tokens per employee become useful here not as a goal to maximize, but as a signal that AI is absorbing the right kind of work at the right pace.
Teams consuming the most tokens learned early that AI adoption isn’t a feature upgrade—it’s a shift in operating model. As AI takes on more responsibility, failure modes surface faster and on a larger scale.
The leaders who navigate this well invest early in:
This ensures that as human intervention scales down, trust scales up—without sacrificing reliability.
PlayerZero is not simply another AI tool provider—it operates using the same patterns as the top AI-consuming companies themselves. Its platform reflects deep AI integration, using meaningful token volume to model, reason about, and execute cognitive workflows that would traditionally require specialized engineers.
At its core, PlayerZero’s agents are designed to mirror how real teams work:
For enterprise engineering teams, the impact shows up quickly—faster issue resolution, fewer customer-facing incidents, more stable releases, and higher throughput without adding headcount. AI projects also reach time-to-value faster because the surrounding reliability system can keep pace with AI-driven velocity.
This pattern plays out across customers like Cayuse, a research management platform with more than 20 interconnected applications and a highly fragmented multi-repo architecture. Before PlayerZero, they relied on slow, reactive workflows to resolve customer issues. With PlayerZero, the team identifies and fixes 90% of issues before they reach the customer. Time to resolution dropped by 80%, junior engineers began handling investigations independently, and high-priority ticket volume declined—resulting in a noticeably smoother customer experience.
Cayuse’s transformation reflects a broader pattern: when AI-driven triage and root-cause analysis sit inside core engineering workflows, teams gain real operational leverage—measured in speed, reliability, and customer outcomes—not just in token consumption.
The list reveals a shift toward AI-driven work, where agents execute cognitive tasks with human oversight. The real metric to watch is tokens per employee, a proxy for how much work each person can offload and how quickly teams can deliver.
Meaningful AI adoption isn’t about experimentation—it’s about redesigning work so AI becomes a true executor, not just an assistant.
For engineering leaders navigating large-scale AI adoption, the real value shows up in metrics like velocity and operational efficiency. The next step is clear: enable AI-native workflows safely—without trading speed for stability.
Explore how PlayerZero helps teams scale AI adoption while maintaining reliability and customer trust.
2026-04-16 15:49:18
On April 2, 2026, the IMF published a note signed by Tobias Adrian that comes as a wake-up call: the tokenization of financial assets is not a marginal improvement of infrastructure. It is a structural reconfiguration of global finance, and it carries systemic vulnerabilities that regulators do not yet master.
But the IMF stops where the question becomes truly interesting.
\
The note identifies four distinct risks. The one that stands out the most, when taking a systemic view of blockchain, is the first: speed as a crisis amplifier.
In the traditional financial system, the two-day settlement delay (T+2) is not an inefficiency to be corrected. It is a discretionary buffer.
It gives central banks, clearing houses, and human actors time to detect a problem before it spreads. Tokenization has removed it. Transactions settle in an atomic, instantaneous, final, irreversible manner. The IMF writes that crises “will likely unfold faster, leaving less time for discretionary intervention.”
This is correct, at least today.
\
The IMF diagnoses speed risk at the macroeconomic level. What it does not say is that this risk operates continuously, at the level of each transaction, long before regulators can intervene. This is already a problem today when humans execute transactions; it is amplified with the deployment of deterministic (programmed) agents, and it will intensify further with the deployment of AI agents on blockchain networks.
An autonomous agent executing an arbitrage strategy on a layer 2 blockchain (rollup) at 3 a.m. does not wait for a central bank announcement. It acts. And if it acts without perception, it acts blindly.
Developers account for almost everything, and AI agents are structured, architected, and equipped with bridges that allow them to fetch near-instant information to secure their transactions, based on their own algorithms.
But is this information reliable? The global system and its interdependencies evolve according to the actions of the agents themselves.
Their main challenge is to position themselves relative to the nominal regime of this environment. This regime is shifting in the short, medium, and long term.
This is where the IMF’s four risks converge into a single operational problem: the absence of a definition of the nominal.
\
In materials science, one does not describe a bridge as “stable” in absolute terms. One defines its nominal behavior range, the conditions under which it deforms in a predictable and reversible way. Outside this range, the material fails.
Blockchain is no different. Ethereum, Solana, Avalanche, layer 2 blockchains, cross-chain bridges, oracles, etc., all have a nominal behavior: a state in which gas fees, finality times, revert rates, and bridge delays fluctuate within predictable bounds. This nominal is not a fixed value. It is a dynamic distribution, continuously measured over sliding windows.
When the IMF refers to “fragmentation of liquidity into digital silos” or “cascading liquidations driven by smart contracts,” it is describing events of departure from the nominal, a divergence. Moments when the infrastructure behaves differently from what agents, human or autonomous, had anticipated.
\
Here is the scenario the IMF hints at without explicitly naming it.
In 2026–2027, thousands of autonomous agents execute strategies across tokenized networks. Each is individually rational. Each optimizes for itself, based on its algorithmic architecture. But their synchronized behavior, thousands of agents detecting the same arbitrage opportunity at the same microsecond, is itself the cause of the stress they seek to identify or predict.
Individual intelligence produces collective degradation because it is blind to the nominal and to system invariants.
The response to this problem is partly regulatory, but not only. It is infrastructural: each agent must have access to a shared measurement of the network state, a signal that reflects the aggregated pressure of agentic activity on the infrastructure.
The blockchain infrastructure deforms under agentic load; it adapts, modifies its own rules to adapt, and so on.
Like a road connecting two medium-sized cities (two blockchains).
This road is built for cities of a few thousand inhabitants.
The road, initially designed to connect two cities, changes their rules, their “operating system.” It facilitates exchanges and increases their attractiveness. In any case, both cities eventually have more inhabitants (autonomous agents), and, more or less, the road that originally had a nominal regime of a few cars ends up being congested 90% of the time, its new nominal. These traffic jams become so well known to users, this nominal being known, that some begin to take alternative routes, which in turn are developed, which in turn further drive the development of the two cities, and so on.
I invite the reader to explore Thinking in Systems: A Primer by Donella H. Meadows, extraordinary when tackling the understanding of complex systems. She also quotes Paul Anderson: “I have never seen a problem, however complicated, that when approached correctly does not become even more complicated.”
I believe this perspective describes extraordinarily well the blockchain environment and its future with autonomous agents.
When the IMF says that “crises will unfold faster,” it describes a world where the nominal must be known before action, not after the crisis. When it refers to “liquidations driven by smart contracts without possible human intervention,” it describes a world where agents need an exogenous signal of the network state, because no human will be there to apply the brakes.
This signal, this nominal, must be constructed and cross-validated.
Like decentralization, where computation is distributed across multiple nodes and the results are compared.
The nominal could be defined in this way.
But it is still not that simple: there is a key problem raised at the very beginning of this reflection, time. Banks prefer to take time for analysis. Autonomous agents have a strong preference for immediacy.
In addition to a shifting nominal, one must define short-term, medium-term, and long-term nominals, and above all extract divergence at high speed.
And the reasoning continues: when do we consider that this divergence is noise or a truly critical event?
This introduces the notion of calibration. Thank you… Paul Anderson :)
\
One final observation, which came to me while reading the IMF note.
One might think that if L1/L2 networks become more performant, higher throughput, reduced latency, consensus bugs eliminated, the need to measure network state decreases. The opposite is true.
The more performant the networks, the more active the agents. The more active the agents, the more frequent, brief, and difficult to detect stress events become without continuous measurement. The average stability of a highly active network hides very high instantaneous variance.
A six-lane highway can be in perfect condition and completely congested at 8 a.m. on a Monday. The quality of the road tells you nothing about traffic.
I also introduce here the notion of context and narrative in blockchain.
I like to describe narrative as the metrics related to price, gas, etc.
But context? Context is the infrastructure.
You are a developer, and using Claude and LangGraph, you create a state-of-the-art AI agent, a true Formula 1.
Well, context is the state of the infrastructure, the condition of the road, in other words. If it is full of potholes, your Formula 1, even with a V12 engine, will not go very far.
\
The IMF note is a strong institutional signal. It generally precedes coordinated regulatory requirements. Within the next twelve to twenty-four months, regulators will seek to define standards for tokenized asset infrastructure.
These standards will have to include an answer to a question that no one is yet clearly asking: how does an autonomous agent know the state of the infrastructure on which it operates?
Defining the nominal is not optional. It is the foundation of every secure autonomous decision.
2026-04-16 15:44:17
For six months, I was forwarding YouTube links with messages like watch this when you get a chance.
Nobody watched them. I know because I checked.
I run a PR agency. Fifteen people spread across multiple cities, handling 90+ clients, pushing out content across 100+ websites. The kind of operation where every saved hour compounds. So when AI tools started getting genuinely capable - not just demo-reel capable - I wanted my team on board fast.
My first instinct was what most managers do: educate from a distance.
I curated reading lists. Shared threads about prompt engineering. Sent a 40-minute video on how large language models work. I even wrote a team message titled Why AI Matters for Us that three people opened and zero people finished.
The team nodded politely in meetings. Said the right things. "Yeah, sounds interesting." "We'll look into it."
Nothing changed.
Their daily work stayed the same. Same manual processes, same hours spent on tasks that should take minutes. I was surprised that a team managing dozens of clients couldn't pick up tools I found intuitive.
The problem wasn't them. It was the approach.
Sending someone a tutorial and expecting adoption is like handing someone a gym membership and expecting fitness results. The information is available. The motivation isn't.
One Tuesday morning, I tried something different. No pre-reads. No homework. I opened a video call with the SEO team and shared my screen.
"Tell me what you're working on right now," I said. "Explain it as if I've never done your job."
One of them described their keyword research process: manually checking competitor rankings, pulling data from three different tools, cross-referencing search volumes, then compiling everything into a spreadsheet that took half a day to build.
Instead of taking notes, I spoke their task description almost verbatim into an AI assistant - using speech-to-text input to keep pace with natural speech - added a few structural prompts, and ran it.
Here's where the technical setup mattered. I had two data source integrations already connected via MCP (Model Context Protocol): one for keyword difficulty and search volume data, another for SERP analysis. So the AI wasn't reasoning in a vacuum. It pulled real search volume figures, real difficulty scores, real competitor rankings - live, during the call.
The room went quiet.
In roughly 90 seconds, the AI produced a structured keyword analysis that would have taken the team 4–5 hours manually. It wasn't perfect - some competitor assumptions needed verification. But the analytical framework was there, the data were real, and approximately 80% of the mechanical work had evaporated.
Then came the piece that sealed it: because a Google Drive integration was already connected via MCP, the output populated directly into a shared Google Sheet - the same format and location the team already used. No downloading, uploading, or copy-pasting between tabs.
One team member said, "Wait, go back," convinced I had pulled the output from somewhere else. Another asked me to repeat the process more slowly so they could see exactly what happened at each step.
That was not the reaction I got from YouTube links.
This is the part most AI adoption guides skip over.
The keyword research demo worked because of three connected layers, not just the AI model itself:
1. Input method: Speech-to-text input lets me capture the team member's task description at the speed of conversation. Typing would have introduced a bottleneck and broken the flow of the demonstration.
2. Live data connections (MCP integrations): Without real data piped into the model, the AI can only produce generic frameworks. With live SEO data connected, it produced analysis grounded in actual numbers - making the output immediately usable rather than illustrative.
3. Output destination: The result landed directly in the team's existing workspace. This eliminated the adoption friction of "now what do I do with this file?" The workflow closed the loop inside tools they already trusted.
When your AI input, data sources, and output destinations are integrated, the productivity gain isn't incremental. It's a structural change in how work gets done. MCP (Model Context Protocol) is worth understanding specifically because it's the layer that makes this kind of integration possible - it allows AI models to interface with external tools and data sources in real time rather than working from static knowledge alone.
A live demo creates excitement. But excitement fades by Thursday if there's no system to sustain it.
The next day, I gave the team one simple instruction: use AI as your first draft for everything this week. Not as a final answer. Not as a replacement for judgment. As a starting point.
Keyword research? Ask AI first, then verify. Content brief? Get a draft from AI, then shape it. Audit summary? Let AI pull the structure, then add your expertise.
I also told them to treat the AI tool as a thinking partner. Before messaging a colleague when stuck on something, try the AI first. Not because the colleague's perspective doesn't matter - but because the AI can get you 70% of the way there, and then the colleague conversation becomes about the remaining 30%, which is where the real expertise lies.
The first two days were predictably messy.
Prompts were too vague. The outputs were too generic. Someone asked the AI to "make a good SEO strategy" and received exactly the surface-level response you'd expect from that broad a prompt.
By day three, the prompts started improving. "Analyze the top 5 ranking pages for this keyword and tell me what content gaps exist." "Give me 10 meta descriptions for this page, each under 155 characters, targeting informational intent."
The quality of AI output is directly tied to the specificity of the input. This sounds obvious in retrospect. But most teams don't internalize it until they've seen the contrast between a vague prompt and a precise one, side by side.
Within four days, three things emerged organically that would have taken weeks through traditional training:
1) Prompt libraries. Team members started saving prompts that produced reliable outputs and sharing them in a group channel. Nobody asked them to. The behavior emerged because they saw direct value in it.
2) Chained workflows. One person used AI to generate a content brief, fed that brief back into AI to produce a first draft, then used AI again to evaluate the draft against SEO best practices. A three-step workflow they invented themselves, without instruction.
3) Shifted relationship to the tool. The initial anxiety - "Is this going to replace what I do?" - shifted into something more productive. The AI handled the mechanical scaffolding. The team handled the judgment, the creative angles, and the decisions that require genuine expertise.
That shift didn't come from a speech about the future of work. It came from spending a week watching the AI handle the tasks they liked least.
Tasks that previously took half a day now take roughly 90 minutes. Not because the AI does everything, but because it handles the scaffolding - the research compilation, the first-draft structure, the repetitive formatting - while the team focuses on judgment and quality.
Content output has roughly doubled without increasing headcount. Same team, same hours, different allocation of time.
This aligns with broader data: OpenAI's 2025 Enterprise AI report found that average enterprise users save 40–60 minutes per day with AI tools integrated into their workflows. McKinsey's 2025 workplace study found that while 92% of companies plan to increase AI investment, only 1% consider themselves mature in actual deployment - suggesting most of the gain is still ahead.
The gap between teams that have integrated AI into daily operations and those that haven't isn't going to be marginal. For agency-style work specifically - content-heavy, deadline-driven, reliant on research and first drafts - the compounding effect of daily AI use adds up quickly.
If you're running a team and trying to move past the tutorial-forwarding phase, here's what actually worked:
1) Skip the pre-reading. Start with a screen share. Take 90 minutes. Use your team's actual current tasks, not hypothetical examples. Let them see the output in real time, with real data, landing somewhere they recognize.
2) Integrate before you demonstrate. A demo where the AI pulls live data from your actual tools is orders of magnitude more persuasive than one where it reasons from general knowledge. Set up the integrations first. The "wait, go back" moment comes from the output being immediately recognizable and usable - not from the AI being impressive in the abstract.
3) Give them one rule for the first week. AI is your first draft, not your final answer. This framing removes the pressure to trust the output completely while still forcing daily contact with the tool.
4) Expect the first two days to be bad. Vague prompts produce generic output. The team needs to experience this directly, not be told about it. By day three, prompts get sharper because the feedback loop is immediate.
5) Let the behavior emerge. Prompt libraries, chained workflows, creative applications - these appeared without instruction once the team had enough hands-on time. Over-structuring the adoption process can actually slow this down.
The tutorials will always be there. But your team doesn't need more information about AI. They need a reason to believe it's worth their time - built from their own tasks, their own data, and an output they can immediately use.
Show them that, and the adoption takes care of itself.
2026-04-16 15:00:57
As global commerce continues to evolve, companies are under increasing pressure to offer more than a single product or a short-term transaction. People are looking for ecosystems that create ongoing value, fit into everyday life, and give them more reasons to stay engaged over time.
JIFU has built its business around that idea. By bringing together travel, wellness, and financial education within one platform, the company has created a model that is designed to be both practical and expansive. Rather than limiting participation to one category, JIFU offers a broader lifestyle ecosystem that gives people multiple ways to connect with the business and with the wider community around it.
That structure matters. In many traditional business models, engagement tends to rise and fall around one offer, one campaign, or one product cycle. JIFU takes a different approach. Its platform is built to support continued interaction across several areas of value, which helps create a stronger and more consistent foundation for long-term growth.
Travel is one of the clearest examples of this. Within JIFU, travel is not positioned as an occasional extra. It is part of the company’s identity and part of the experience people associate with the brand. It brings lifestyle value into the business in a way that feels tangible, memorable, and easy to understand. In a crowded market, that gives JIFU a point of distinction that is both commercial and cultural.
The same can be said for the company’s wellness offering. Wellness remains a major area of consumer interest globally, but what differentiates stronger companies in this space is not simply participation in the category. It is the ability to integrate wellness into a broader business model in a way that feels coherent. JIFU does this by placing wellness alongside travel and education, rather than treating it as a stand-alone concept. The result is a more complete ecosystem, where each vertical reinforces the strength of the others.
Another important part of the company’s model is community. JIFU operates across different regions and markets, which means the business is not defined by one geography or one audience. That global reach brings diversity of perspective, but it also requires a clear sense of alignment. A business of this nature only becomes stronger when people feel connected not just to a product line, but to a broader vision and shared direction.
JIFU has shown a clear understanding of that. The company has continued to invest in experiences that bring people together, strengthen relationships, and reinforce culture beyond digital communication alone. In a business environment where so much happens online, those real-world moments matter. They create trust, deepen loyalty, and remind people that they are part of something larger than an individual transaction.
That is part of what makes JIFU’s model notable. It does not rely on one source of value. It combines product, lifestyle, education, and experience into a single business ecosystem that is designed to stay relevant across different forms of engagement. This gives the company more resilience than a narrow model built around one offer alone.
It also positions JIFU well for a market that is changing quickly. Consumers and business builders alike are becoming more selective. They are drawn to platforms that feel multidimensional, globally minded, and aligned with how people actually want to live. Businesses that can combine utility with experience are often better placed to sustain attention and loyalty over time.
JIFU’s continued growth reflects the strength of that direction. By building a platform that connects travel, wellness, financial education, and community, the company has created a business that feels broader than a single category and more adaptive than a traditional model. Its appeal lies not only in what it offers, but in how those offerings work together to create a more connected and dynamic experience.
As the company continues to expand, that integrated structure may prove to be one of its greatest advantages. In an increasingly competitive landscape, JIFU is not simply participating in the conversation around modern business. It is building a model that reflects where that conversation is already going.
\
:::tip This story was distributed as a release by Jon Stojan under HackerNoon’s Business Blogging Program.
:::
\
