Santu Patra

The problem Phoenix AI solves Phoenix redefines AI agents by merging usability, extensibility, and real-world functionality in a browser-first, blockchain-powered platform. 🔧 1. From Chat to Action Problem: Most AI UIs are passive. Phoenix: Empowers agents to take real actions using dynamic tools like shell commands, web search, and email. ⚙️ 2. Runtime Tool Selection Problem: Toolsets are usually static. Phoenix: Lets users plug in tools per session, no redeploys or backend changes needed. 🧱 3. No-Code Agent Builder Problem: Building agents is backend-heavy. Phoenix: Offers a Prompt Playground and browser-based UI to craft and test agents — zero backend required. 🔗 4. Blockchain Agent Ownership Problem: No on-chain identity or ownership. Phoenix: Agents are minted as NFTs, stored on IPFS — enabling decentralized deployment, access control, and ownership. 🛒 5. On-Chain Agent Marketplace Problem: No trusted way to sell/share agents. Phoenix: A blockchain-powered marketplace where: Creators list agents with on-chain pricing Buyers unlock access via token/NFT Ownership and access are verifiable and trustless Phoenix: Not just smarter agents — ownable, functional, and ready for the real world. Challenges we ran into Notable Obstacles & How We Overcame Them **🔗 1. Publishing Agents to the Blockchain Obstacle:** We wanted users to mint and trade AI agents as on-chain assets (e.g., NFTs), which raised challenges around metadata storage, immutability, and dynamic tool inclusion. How We Solved It: Used NFTs to represent each agent, storing agent metadata (e.g. prompt, tools, config) on IPFS via Pinata for decentralized, tamper-proof storage. Designed a clean agent export format (ai_config) to serialize agent logic and selected tools. Integrated smart contracts (EVM-compatible) to mint agents and attach encrypted IPFS metadata URIs. **🛡️ 2. Securely Accessing Agents from the Blockchain Obstacle:** Once published, we needed a secure method to allow only authorized users (e.g., NFT owners or subscribers) to load and interact with private agents and their toolchains. How We Solved It: Leveraged Lit Protocol to encrypt and gate access to private agent files and configurations. On-chain access control is enforced by verifying NFT ownership or active subscriptions before decrypting agent config files. Client-side logic (Next.js + Wagmi) interacts with Lit SDK and smart contracts to unlock tools and configs only for eligible users. **🔐 3. Connecting OAuth-Based Tools Securely Obstacle:** Some tools (like Gmail, YouTube, Calendar) require OAuth 2.0, which complicates integration due to token management, user-specific scopes, and potential misuse. How We Solved It: Integrated NextAuth.js with Google OAuth to handle login, token refresh, and session security. Used server-side API routes to proxy OAuth-based tool requests (e.g., send/read email), preventing direct client access to tokens. Scoped each tool to the authenticated user’s session and ensured tools could not be invoked unless a valid token was present.