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:

1. Creators list agents with on-chain pricing
2. Buyers unlock access via token/NFT
3. 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.