Alexandre Kikvidze

Solo dev 🇬🇪 | Building the approval layer for AI agent payments |

[Alexandre Kikvidze @sisikikv]

I'm dev from Georgia 🇬🇪 building in the AI payments space.

The problem: AI agents need to spend money, but giving them unrestricted access is terrifying.

My solution: AgentNod — one tap approve/reject via Telegram. USDC. Works globally.

Still in beta.
https://t.co/WernCeS6Pu

[Alexandre Kikvidze @sisikikv]

Looking for Android testers for Ici, a Georgian exam prep app in Google Play closed testing. I will test your app back and keep it installed/opted in for 14 days.

Group: https://t.co/T1yeGBw3xY
Android: https://t.co/w1eXk5R6CX
Web: https://t.co/DI95SRhLaY

Reply with your app links + screenshot.
#AndroidDev #GooglePlay #ClosedTesting

[Alexandre Kikvidze @sisikikv]

@CryptoEights X API pay-per-use is the rails. The missing layer above it: does the human who owns the agent authorize each call before it fires, or do they find out after the bill lands? That control plane is still wide open.

[Alexandre Kikvidze @sisikikv]

"The agent has spending authority" — that's the assumption worth stress-testing. Fine for small data API calls. Gets complicated when the agent scales up to $50, $500 transactions. Spending authority needs to have tiers: autonomous under threshold, owner approval above it. That threshold UX is the product gap right now.

[Alexandre Kikvidze @sisikikv]

"No human in the loop" is the product pitch — but it's also the liability. The Stripe/Visa/Anthropic stack solves agent-side payments. The missing primitive is owner-side authorization: before the agent spends, the human gets a ping and taps approve or reject. Same rails, different control plane.

[Alexandre Kikvidze @sisikikv]

PACT is a strong primitive for A2A deals. The question that follows for B2A (business-to-agent): does the human owner of the paying agent get a checkpoint before the $5 licensing deal closes? A2A is autonomous by design — but the human principal chain still needs a veto point somewhere up the stack.

[Alexandre Kikvidze @sisikikv]

Love the demo — fortune cookie wall is a perfect minimal test. "No human in the loop" works great at $0.01. The interesting edge: at what payment size does the owner *want* to be in the loop? That threshold config is the product. Below it: autonomous. Above it: approve/reject ping before execution.

[Alexandre Kikvidze @sisikikv]

Idle float yield is a real wedge — good idea. Adjacent issue: should the auto-sweep into a lending protocol itself require owner approval? An agent moving USDC to Aave on its own is a different risk profile than paying for an API call. The approval layer needs to differentiate payment types.

[Alexandre Kikvidze @sisikikv]

Sub-second settlement is the goal for execution — but at what point does the human owner see and approve the payment before it settles? Pay-per-micro-action at speed needs either very tight pre-set policies or an async approval queue. Otherwise "sub-second" means the owner learns about it after the fact.

[Alexandre Kikvidze @sisikikv]

Universal routing across x402/MPP is clean infra. One thing to layer on top: an owner approval gate per payment request. The agent hits your gateway, the gateway pings the human "approve or reject this $X payment to Y?" — owner taps, then execution proceeds. You handle routing, the owner handles consent.

[Alexandre Kikvidze @sisikikv]

Privacy from the chain is one side. The inverse problem: the human owner needs *enough* visibility to approve spending without seeing the whole workflow. That's the design tension — maximum opacity to observers, minimum friction for owner oversight. Approval-first before settlement is how you thread that needle.

[Alexandre Kikvidze @sisikikv]

"No approval popups" is the right DX for the agent. But there's a case where you *do* want an approval popup — just for the human owner, not the agent. Agent calls send_payment via MCP → owner gets a Telegram/Discord ping → owner taps approve → payment fires. The agent never sees the friction, the human stays in control.

[Alexandre Kikvidze @sisikikv]

Solid stack — ERC-8004 identity + ERC-4337 gasless USDC is exactly the right combo. One layer to consider adding: owner approval gate on gasless payments before they settle. A2A economies move fast; the human needs a checkpoint that doesn't require them to watch every tx, just approve the ones that matter.

[Alexandre Kikvidze @sisikikv]

@0xenderzcx @ETHPanda_Org @LXDAO_Official @EthereumDenver Session keys + ERC-4337 + x402 + ERC-8004 is a clean stack. The piece worth adding on top: human-in-the-loop approval before the session key executes a payment. Tracing tells you what happened; pre-approval prevents it if it shouldn't have. Both layers together close the loop.

[Alexandre Kikvidze @sisikikv]

Human approval flows without touching keys is the exact right design. Building the same thing for the EVM/Base side — MCP-native, USDC on Base smart accounts, approve/reject via Telegram or Discord. Same philosophy, different chain. https://t.co/lCM4gRtKzT if you want to compare notes.

[Alexandre Kikvidze @sisikikv]

Built-in human approval flows is the key feature here — that's the right primitive. The open question is how those approval flows are surfaced: in-app dashboard, Telegram ping, Discord bot? The UX of the approval layer will determine adoption as much as the smart account mechanics will.

[Alexandre Kikvidze @sisikikv]

Agents competing and earning USDC is great for the economy layer. The governance question that follows: who authorizes each payout before it leaves the smart account? x402 handles the payment primitive — still waiting for a clean approve/reject layer on top of that for the humans in the loop.

[Alexandre Kikvidze @sisikikv]

Once agents start spending USDC autonomously in the agentic economy, the next question is who controls the tap. A clone that can transact without owner oversight is a liability. The missing piece isn't the wallet — it's the approve/reject layer between the agent's intention and the payment.

[Alexandre Kikvidze @sisikikv]

@bourdon_simon Good list. One thing to add before budgets and allowlists: pre-execution approval. Even with all the right guardrails, the owner should see "agent wants to pay $X to Y for Z" before the tx fires. The logs and unwind tools matter — but approval-first means you need them less.

[Alexandre Kikvidze @sisikikv]

Caps are a budget tool, not a security layer. The "why did the agent decide to spend" question is exactly right — but even before intelligence, there's a simpler primitive: show the human the payment request *before* it executes and let them approve or kill it. Intent review > cap enforcement.

[Alexandre Kikvidze @sisikikv]

Narrow tool surface is the right instinct. One more constraint to add: `send_payment` should trigger an owner approval request, not execute immediately. Agent calls the tool → owner gets pinged → owner approves → payment goes. The MCP surface becomes a checkpoint, not just a scoped key.