Interview with Katrina Laszlo for Pricing for the Agent Economy
Interview July 17, 2026 with Steven Forth
“The unifying theme across my work is that pricing is not separate from the product experience; it’s part of it, and increasingly central.”
Key Points
Katrina’s career arc—from design thinking and innovation labs through VC/startup incubation and API product work—has led her to treat pricing as an integral part of product and customer experience, not a separate function.
Tanso builds pricing and monetization infrastructure for AI and API‑driven startups, combining flexible mechanisms (credits, rollovers, top‑ups, pooling) with unified visibility into cost, revenue, and usage.
Katrina distinguishes “credits” as a broad label for usage‑based pricing from “credits as synthetic currency.” The term “credits” is used broadly and inconsistently across the industry. Companies often use it to describe prepaid balances and usage-based mechanisms with or without synthetic currency.
She sees the rise of headless, API‑centric products and agents doing work on behalf of humans as key drivers of the shift away from seat‑based pricing toward usage and credit‑like models.
Her guiding principle for credit design is customer centricity: strong credit systems give companies flexibility while helping customers understand what their balance can buy, what different actions consume, and how usage connects to dollar spend and value.
About Katrina and Tanso
Katrina Laszlo is the co‑founder and CEO of Tanso, where she leads the design and development of monetization infrastructure for AI and SaaS companies. She draws on a decade of experience across product, engineering, and design to shape Tanso’s vision of pricing as a core part of the product experience, from usage metering and credit systems to experimentation and agent‑centric interfaces.
Tanso https://tansohq.com/ is open-source pricing and monetization infrastructure for AI and B2B software companies. It helps companies meter usage, understand cost and revenue at the feature and workflow level, and support flexible models such as credits, prepaid balances, included usage, overages, rollovers, top-ups, pooling, and entitlements.
Tanso treats pricing as part of the product experience and gives companies a unified view of how usage, cost, and revenue relate. This is especially important for AI companies whose products rely on third-party models and infrastructure and whose economics may vary significantly across features, workflows, and customers.
Interview
Katrina’s background and path
I started my career in innovation and venture building during the early design-thinking period. My first role was at Ernst & Young in its innovation lab and design studio, where we built and incubated ventures with financial services institutions.
I’ve always been entrepreneurial, so that environment of experimentation and venture building was a natural fit. From there, I moved to 500 Startups, where I was again incubating ventures, but this time working alongside corporates and connecting them with startups they could run proofs of concept with. It was not just building internally; it was also evaluating whether it made sense to invest or partner, which gave me a broader view of how innovation, product, and commercialization fit together.
Working with those startups made me want to go back into building myself. That led me to People Data Labs, a B2B data enrichment company that has become very relevant in today’s ecosystem, where I worked on their API product and developer experience. That role covered everything from a customer’s first visit to the website, to how they evaluate the product, how they self-serve, and ultimately how they pay for it.
In that context, the “product experience” was far more than just the interface. The interface was a mechanism for a lot of other interactions: pricing, packaging, how customers could purchase different field bundles for different use cases. The unifying theme across these experiences was that pricing was not separate from the product experience; it was part of it, and increasingly central.
After People Data Labs, I had the opportunity to head product at a company called Chipper, where I met my co‑founder. I then briefly worked at an AI startup, and I saw the same pricing themes reappearing, but now much broader: not just for API companies, but for a new wave of startups grappling with questions like “How do I price my product?” and “Should I do outcome‑based pricing?” The common thread was a growing need for flexibility.
My co‑founder Douglas Baek and I realized: we’ve built this before, and there are now many startups that are going to need it. It felt like the perfect timing to start Tanso. That’s my story in a nutshell; it sometimes feels like a very long career when I walk through it, but the themes have been consistent.
Vision and focus at Tanso
At Tanso, I’m focused on what a good product experience looks like as the boundaries of “product” expand beyond a traditional web or SaaS interface. We’re asking: what does design look like when the user interface shifts, whether a user is in a cloud dashboard, a developer console, or interacting through an agent rather than directly as a human?
Pricing and billing are becoming a much bigger part of the product experience. With Tanso, we have built pricing and monetization infrastructure for AI and B2B software companies whose usage, costs, and revenue are increasingly variable.
These companies often need flexible mechanisms such as included usage, prepaid balances, credits, rollovers, top-ups, overages, pooling, and entitlements. They also need to understand whether their pricing is working. Because many AI companies rely on third-party models and infrastructure, cost is a first-order concern.
What makes Tanso distinctive is bringing usage, cost, and revenue together so a company can understand the economics of a feature, workflow, agent run, or customer and use that information to make better pricing and packaging decisions.
At the same time, these companies need to understand what is effective and what isn’t in their pricing, and they have more factors at play because almost everyone is building on third‑party resources. Cost is a first‑order concern. What makes Tanso unique is combining flexibility with transparency: bringing your cost, your revenue, and your usage into one place so you can see how they fit together in a coherent, actionable way.
Ideal customers and use cases
Tanso is most relevant for AI and B2B software companies whose revenue and costs depend on what customers actually consume.
That includes AI agents, voice AI products, vertical AI applications, API businesses, and SaaS companies moving from purely seat-based pricing toward usage-based or hybrid models.
These companies often rely on third-party models and infrastructure, which makes both their costs and their customers’ usage variable. They need to understand the cost and revenue of a complete workflow or agent run, determine how to package and price different capabilities, and support mechanisms such as included usage, prepaid balances, credits, top-ups, rollovers, pooling, and overages.
They also need to expose pricing, balances, usage, and limits to customers in a way that feels intuitive. That is where monetization infrastructure becomes part of the product experience rather than simply a back-office billing system.
Pull quote:
“We’re seeing a shift toward ‘headless’ products— more companies beginning to operate like API companies because consumption increasingly happens programmatically and outside the traditional interface. In that world, charging by seats doesn’t align with value delivered.”
How I think about “credits”
The word “credits” is used broadly across the industry. Companies may use it to describe prepaid balances, top-ups, rollovers, pooling, or usage-based pricing more generally. However, those mechanisms can all be implemented either directly in dollars or through credits as a synthetic currency.
Usage-based pricing describes what changes with consumption. Prepayment and arrears describe when the customer pays, while top-ups, rollovers, and pooling describe how the balance is managed.
Credits add another unit between dollars and the underlying usage. For example, a customer could prepay $100 and spend it directly on actions priced in dollars, or receive credits and spend a set number on each action.
Both structures can support the same balance mechanics. The difference is whether there’s an additional unit between dollars and usage. Synthetic currency can be especially helpful when costs are shifting and you want to show customers something that doesn’t change constantly. It can make a volatile cost structure more palatable by stabilizing what the customer sees and pays for, as long as it doesn’t obscure the value they receive.
Why companies are moving to usage and credits
We’re seeing more products operate programmatically, with usage happening outside the traditional dashboard through APIs and agents acting on behalf of people and organizations.
In that environment, seats become a weaker proxy for usage or value. One user may generate very little activity, while another may initiate thousands of automated actions. If agents do work that people previously did, there may also be fewer seats to sell.
Usage-based pricing gives companies a way to connect revenue more closely to what customers consume and, ideally, the value they receive.
Why credits are becoming more common
Credits are becoming more common because they give companies one commercial unit across different kinds of usage.
That lets a company package multiple products, actions, models, or resources without asking the customer to understand every technical unit underneath. It also allows relative prices to change while the purchasing and balance experience stays more stable.
This is especially relevant for AI companies, where models, infrastructure, and product capabilities can change quickly. The strongest credit systems pair that flexibility with clear usage reporting, forecasting, and explanations of what different actions consume.
Tokens vs. credits
Tokens can play different roles depending on how a company designs its pricing.
Model providers often use tokens directly as both the usage metric and the pricing metric. For example, the OpenAI API charges in dollars based on the number and type of tokens consumed. Customers can fund that usage with prepaid API credits, but those credits function as a prepaid dollar balance.
OpenAI also uses credits differently for Codex. In that system, credits are the commercial unit the customer consumes, while the underlying input and output tokens determine how many credits are deducted.
A company building on a model provider may use the same structure: track token consumption underneath, but charge its customers in credits for an action or workflow.
Some third-party products also call their own synthetic currency “tokens,” even when those units do not correspond directly to the model tokens consumed.
So a token may be a direct usage and pricing metric, an underlying usage metric within a credit system, or the name given to a synthetic currency. The role depends on how the company defines and uses it.
Addressing objections to credit-based pricing
There’s understandable pushback around credits: people say they’re hard to understand, hard to predict, and hard to connect to value. If customers have to dig through FAQs or do their own calculations to work out what a credit buys, that can create friction in product evaluation. This doesn’t make credits inherently bad, but it raises the bar for how the system is designed and communicated.
Credits can be useful when the underlying economics move quickly. They give companies more room to adapt as models, infrastructure costs, and usage patterns change, while keeping the customer-facing experience relatively consistent.
That flexibility works when the connection to value remains clear. Forecasting, usage projections, and budget controls become more important when there is an additional layer between dollars spent and units consumed.
Design decisions in credit systems
The most important starting point in designing a credit‑based system is aligning on your value metric: what does a customer actually get from using your product? That value metric doesn’t have to be the same as your usage metric, but in practice customers want to understand what they get for each dollar, so you need a transparent way to express that relationship.
From there, a lot of design work involves the broader customer experience: not only what the value or credit metric is, but how usage and commitment play out over time. For example, if customers want more flexibility in their usage over a period, you have levers like enabling annual plans rather than monthly plans, allowing rollover credits so they can use more the following month, or adding top‑ups mid‑cycle.
Each of these levers has trade‑offs, and the right choice depends on your product and your customers’ usage patterns. You need visibility into those patterns to decide, when a customer asks for more flexibility, what the best approach really is.
One important dimension is whether you offer product‑specific credits or product‑agnostic balances. If you design everything as product‑specific upfront, you can run into problems later when customer success realizes a customer misestimated usage for one product and needs to shift unused balance to another. Being able to move value across products can be a powerful lever for retention and renewal.
Product‑agnostic credits also support experimentation. You can introduce new products against the existing balance, encourage exploration of new use cases, and increase stickiness without forcing separate upfront commitments for each product. Even if you don’t enable product‑agnostic credits on day one, it’s usually wise to architect your system to support that option down the road.
Another design axis is pooling credits at the organizational level and controlling who can use what, with limits over time. These systems can be difficult to implement and tricky from a policy perspective, especially when multiple groups within a company are making changes in different areas. You want to build your system so it supports pooling and governance without introducing chaos or bugs as usage scales.
Guiding principles for pooling, rollovers, and flexibility
The core principle I come back to is customer centricity. If your credit system becomes so complicated that customers have to do significant math to understand what they’re getting for their dollar or to project their usage, that’s a problem.
It’s very easy to over‑architect these systems, especially if you don’t have a clear reason for using synthetic currency or credits in the first place. If you treat credits primarily like an arcade or reward system without grounding them in value, you risk introducing complexity that doesn’t contribute to your goals.
You also have to remember that while your internal team may be deeply familiar with the lexicon you’ve developed around credits and value, customers are often encountering it for the first time. Taking their perspective seriously and simplifying as much as possible is crucial—at least while your customers are humans.
Looking ahead: agents and the buying experience
Right now, agents are already being used to evaluate different products and to read and interpret websites. I think we’re going to see websites designed for two audiences: humans and agents.
For humans, brand, visuals, and marketing language matter; they influence how a person feels about and understands a product. But the agent, as the evaluator, may be producing a synthesized report rather than experiencing the site as a human does. The agent doesn’t get the full aesthetic and narrative experience; it gets structured data and content.
That split creates both challenges and opportunities. Agents are less likely to be overwhelmed by additional information, and you don’t have to worry about whitespace or visual hierarchy in the same way for them. You can imagine a website that effectively has two layers: one optimized for human readers, and another optimized for agents doing evaluation, procurement, or due diligence.
On the self‑serve and onboarding side, agents are not yet central, but I expect them to become a bigger part of that process and of B2B spend more broadly. Agents will play a larger role in evaluating products, making recommendations, and potentially initiating transactions. The interesting part is that you can already start testing and exploring those patterns today.