I am building in the space of agentic commerce and payments. DM for partnerships.
Things that grab my attention:
Problem Solving
Physics
Complex numbers
Coffee
I completely agree that just as agents should be able to tirelessly work in the background for delegated chores, they should also be able to make the visual experience of purchasing orders of magnitude better than what we have today.
Imagine talking to your agent and having it generate an adaptive, intelligent UI that lets you browse, negotiate, and complete a purchase. This is a glimpse of what I am building for agent builders and merchants.
Wrote a few thoughts on co-browsing because I think a lot of the agentic commerce conversation on here misses what we’re seeing in the real world about how normal people actually shop with AI https://t.co/mYMrFlj3w4
I wrote this article purely for my own benefit. I wanted to be able to organize my thoughts around a subject that I've spent lots of time researching/thinking about. I shared this with some friends who said I need to publish it.
Hope you enjoy. https://t.co/63nlCpE4YP
Not exactly. MCP tools can be accessed through user scoped bearer tokens. Today, to get the bearer token the user is routed to a oauth shaped webpage to authenticate with an identity (phone/email etc). That's the only step where the browser comes in. It is not needed for subsequent invocation of the tools.
In fact with deeper partnerships even this step can be simplified significantly.
In fact better consumer experiences can also be built if merchants provide their reseller APIs and rely on the reseller/partner to send in the customer identifier.
Almost anyone using an agent will have noticed that when the agent searches the internet, it is essentially making a tool call either to its own backend or to platforms like Exa, Parallel Web Systems or Tavily. Agents don’t open https://t.co/us1H9BZUM2 on a cloud browser, input the query, scrape links out of the DOM, and navigate around. It seems obvious that the latter is not an efficient solution.
Similarly, agents opening merchant websites and navigating the DOM to effect a purchase is NOT the efficient shape for agentic commerce. Agents need an "agent-native fastlane" for agentic commerce to scale up.
Granted that some merchants are already publishing their MCPs in the marketplaces of the agent providers, however, I believe there is a unique opportunity to build a unified, fast-lane platform where agent builders can connect to multiple merchants through a single pipe essentially acting as a universal commerce navigator for agents.
The incentives for agent builders:
Cost efficiency: Fewer tokens between intent and a consequential action thereby reducing the cost of successful outcomes
Commercial outcome: One agreement instead of multiple contracts. One pipe that makes money for every successful transaction.
For merchants, the opportunity is not just exposing tools an agent can invoke, but getting distribution across every agent surface from one integration.
I want to build a completely headless bank (NO branch, NO netbanking app, NO mobile app) which can be accessed via hardened APIs (think Oauth 2 + FAPI + some proprietary stuff). The account holder as the subject can build whatever user interface they want, and can use whatever agents they want. We will ensure best in class security, privacy and reduced fraud.
The bank will ONLY be run by engineers who have a deep sense and understanding of software, cryptography, security and physics. Every metric in banking treasury and risk management will be looked at from first principles and software systems will be designed around it.
This is my version of Renaissance technologies in the banking world. I want to be super clear, this is not a bank for everybody, this is a bank for AI natives.
Granted that today getting an approval for a de novo banking charter is impossible for a team like this but in reality this is the team that can build the bank of the future.
There is NO technical means by which a merchant can identify an agent today. The user-agent, headers, TLS fingerprints (JA3/JA4), HTTP/2 frame ordering, JS execution challenges, canvas fingerprints, mouse-entropy models the server receives are fundamentally bytes a program can produce/reproduce. The way to get around data center IP ASN bans is to route via residential proxies OR route through the humans device. Basically a headless chromium replaying a recorded human trajectory produces the same wire bytes as the human.
In my opinion there are 3 levers that can be pulled to gather momentum here
1. Think of agents as untrusted execution environments. Agents communicate the intent to pay but never have access to the payment credential. The payment takes place out of band either with human approval just in time or ahead of time (mandate). This improves the exposure significantly and allows for creating a purchase protection layer and solve for economic liability.
2. A take rate from the merchant that is shared by the agent builder and the intermediary building 1.
3. Providing granular observability to merchants. This becomes credible once there is enough volume and traction.
https://t.co/eRX3NxJicP
I published a deeper dive on Stripe Link balance. Please read, debate and disagree. Happy to be challenged and improve my understanding.
In my last post I had mentioned that I will publish a deeper dive peeling the layers of Stripe Link balance. Here you go. Please debate, disagree. Happy to be challenged and improve my understanding. https://t.co/B4XHIwx52B
In my last post I had mentioned that I will publish a deeper dive peeling the layers of Stripe Link balance. Here you go. Please debate, disagree. Happy to be challenged and improve my understanding. https://t.co/B4XHIwx52B
I have been studying the product “Stripe Link” balance. The choice of going forward with the stable coin backed prepaid card is quite interesting. IMO, Stripe will use this link balance product as a conduit to further the cause of their crypto initiatives. The math around net interchange, block chain gas fees and operational complexity of stripe treasury managing between fiat and USD may be hard to wrap around in the short term but one can sense a structural advantage getting built. Of course things may not always work out as planned but very interesting times ahead.
I wanted to continue from the previous post https://t.co/HhEuHWEsPt and share more thoughts.
There is literally nothing in an incoming HTTP request to a server that allows the server to deterministically assert that the request has originated from a browser client being used by a human via their eyes and fingers on a device.
The user-agent, headers, TLS fingerprints (JA3/JA4), HTTP/2 frame ordering, JS execution challenges, canvas fingerprints, mouse-entropy models the server receives are fundamentally bytes a program can produce/reproduce. Basically a headless chromium replaying a recorded human trajectory produces the same wire bytes as the human.
You could ask, what's the point of all this information?
Look, the baseline is that merchants cannot keep agents out by technical means. Improvements in the capability of personal agents will shift reality to contracts, economics and law. Merchants will either strengthen their “terms of service” to disincentivise agents or modify them and welcome them with open arms.
This creates two problems and hence 2 unique opportunities to build compelling products.
1. A mechanism for the merchants to identify the agent operating on behalf of the human and offer a seamless and faster lane for interaction and navigation. Just to give you a sense of the problem, requiring humans’ connecting and authenticate 9 MCPs from 9 different merchants periodically for their agents to purchase is not a scalable solution. In fact I would go on to say it's not a solution of the future. I have some thoughts around this and would love to collaborate with merchants on this.
2. Keep payment out of agents. Agents interact with the merchants and hand off to the human to approve the payment. This should cover both the use cases
Just-in-time approval: The human approves the final transaction at checkout, immediately before payment execution.
Approval ahead of time: The human approves a mandate defining the permitted scope and limits of a future purchase. Once the agent discovers a suitable item and merchant, the final transaction details are checked against that mandate before payment execution
An important point to note here is that the human looking at the approval screen reflects reality from the merchant's system of record and not the agent’s provenance of purchase. This avoids prompt injection, hallucination and rogue agent behaviour.
As more and more people use agents for commerce and payments the problem of economic liability is going to surge exponentially. A bulk of it is going to be shifted to consumers as personal liability for providing agency to the agent and some it may be product liability due to product bugs and bad faith agent actors.
Players in the ecosystem are trying to work on agent safe payment tokens that the agent can provide to a merchant for payment. IMO it does not seem like the right way to approach the problem.
Agents should be deemed as untrusted execution environments. Agents will use tokens to reason, interact and negotiate with merchants for arriving at the terminal payment value. The final act of payment orchestration with human consent should occur outside of the agents environment.
As more and more people use agents for commerce and payments the problem of economic liability is going to surge exponentially. A bulk of it is going to be shifted to consumers as personal liability for providing agency to the agent and some it may be product liability due to product bugs and bad faith agent actors.
Players in the ecosystem are trying to work on agent safe payment tokens that the agent can provide to a merchant for payment. IMO it does not seem like the right way to approach the problem.
Agents should be deemed as untrusted execution environments. Agents will use tokens to reason, interact and negotiate with merchants for arriving at the terminal payment value. The final act of payment orchestration with human consent should occur outside of the agents environment.
@saranormous Is there a way to do an in person workshop to understand the workflow? I can get interested folks from India who would be willing to pay, visit and learn.
DOB update is done at the ASK. Try to get it done in the ASK itself.
In case they are unable to fulfil the request is when you should visit the regional office. You need a SRN prior to the visit which can be generated by filing a grievance. (Note the regional office is extremely crowded)
My guess is that the reason they are asking for a secondary document is that the board certificate contains your mother's maiden name whereas the Aadhar has your mother's current surname which has been changed after marriage.
However my reading of this doc https://t.co/WIsXNwZHrJ
pages 9 - 13 (especially the # in page 13) says that the marriage certificate is not mandatory and any acceptable POI should work.
@link@stripe Guys I am in India and unable to use the cli to try out agentic payments. Why are you folks not launching in India?
Btw RBI has extended the definition of devices to include a bunch of consumer devices https://t.co/IAABC87yXa
@GoogleIndia@sundarpichai Quick question. I'm curious, what is stopping you from working with multiple (at least 2) PA-CB license holders for cross border transactions with published KYC approval rates?
IMO, you should try and make lives of developers in India easy instead having to wait for months for an exclusive partner like Billdesk to approve them.