Originally published on AIdeazz — cross-posted here with canonical link.
My first production AI agent, a Telegram bot for real estate leads, cost $0.03 per interaction on Groq. It failed to convert a single lead in its first 72 hours. The "executive experience" I brought to the table—leading a 200-person team, managing a $50M budget, negotiating with government ministers—did not prevent that failure. It also didn't write a single line of Python, debug a KeyError, or configure an Oracle Cloud Infrastructure (OCI) network security group.
For two years, I tried to hide the 15-year gap between my last line of code and my first git commit at AIdeazz. I thought my Deputy CEO title was a liability, a sign I was out of touch. It turns out, some of it was. But other parts, the ones I never expected, are the only reason AIdeazz exists at all.
The Useless Baggage: What Didn't Transfer
The biggest waste of time was trying to apply enterprise-level strategic planning to a solo operation. I spent weeks drafting a 5-year business plan, complete with market analysis and competitive landscapes. My first paying client, a small logistics company in Panama, needed a WhatsApp bot to automate delivery updates. They didn't care about my "vision for global AI transformation." They cared about reducing customer service calls by 20% and paying less than $100/month. My elaborate plan sat unused.
Another surprising dead weight was the expectation of a support structure. As Deputy CEO, I had a team for everything: legal, HR, finance, IT. When my OCI tenancy hit its free tier limits, I spent 4 hours debugging why my oci-cli commands were failing, only to discover I needed to upgrade my billing account. There was no IT department to call. When I needed a simple legal disclaimer for my website, I spent 3 days researching Panamanian corporate law. There was no legal team. This forced me to learn, often painfully, every single operational detail. It was inefficient for a time, but ultimately built a deeper understanding of the entire stack.
Finally, the "power of delegation" was a myth. When you're a solo founder, there's no one to delegate to. Every bug, every deployment, every customer email lands on your desk. The skill of breaking down a large project into smaller tasks and assigning them to specialists was useless. Instead, I had to learn to execute every single task myself, from database design to frontend UI.
The Unexpected Assets: What Actually Helped
While the grand strategy was useless, the ability to break down complex problems into actionable steps, regardless of who executes them, proved invaluable. My first multi-agent system for a client involved integrating with their legacy CRM, a custom-built PHP application from 2008. The initial scope was "automate customer support." I broke it down:
- Data Ingestion: API integration with CRM (read-only).
- Knowledge Base Creation: Embeddings of CRM data + client FAQs.
- Agent Orchestration: Router agent (Groq/Claude) + specialized agents (CRM query, FAQ answer, human handover).
- Deployment: OCI Container Instances, API Gateway, VCN.
- Frontend: WhatsApp Business API integration.
This structured approach, honed over years of managing large-scale infrastructure projects, allowed me to tackle a problem I had no prior technical experience with. It wasn't about how to code the API integration, but what integrations were needed and in what order.
My executive role also involved constant negotiation and stakeholder management. This translated directly to client interactions. When a client insisted on a feature that would add 30% to the development time for 5% perceived value, I could articulate the trade-offs, manage expectations, and guide them towards a more pragmatic solution. I learned to say "no" to bad ideas, not just "yes" to every request. For example, a client wanted a custom LLM fine-tuned on their data, despite having only 500 customer interactions. I explained that a RAG approach with a commercial LLM (Claude 3.5 Sonnet) would deliver 90% of the value at 10% of the cost and time. They agreed.
Finally, the sheer resilience developed from navigating high-stakes corporate politics and managing crises proved essential. When my OCI billing account got suspended for a false positive fraud alert (a common issue for new accounts in certain regions), I spent 48 hours on support calls and emails. My agents were down. My clients were calling. The ability to remain calm, systematically escalate, and persist until the issue was resolved, rather than panicking, was a direct transfer from my executive past.
The Oracle Cloud Infrastructure Bet
I chose Oracle Cloud Infrastructure (OCI) for AIdeazz for two main reasons: cost and the free tier. As a bootstrapped solo founder, every dollar counted. OCI's always-free tier offered Ampere A1 Compute instances (4 OCPUs, 24GB RAM) and 200GB block storage, which was enough to host my initial agent deployments and vector database (pgvector on a free tier PostgreSQL instance). This allowed me to launch production agents with zero infrastructure cost for the first few months.
The second reason was the egress cost. While AWS and GCP offer generous free tiers for compute, their egress data transfer costs can quickly add up, especially for AI agents interacting frequently with external APIs or serving many users. OCI's egress costs are significantly lower, which was a critical factor for scaling. My current monthly OCI bill for all production agents, including a custom-built multi-agent orchestration layer, is under $50. This includes 2 OCPUs, 12GB RAM, 500GB block storage, and ~1TB of egress traffic.
The downside? OCI's developer experience is not as polished as AWS or GCP. Documentation can be sparse, and community support is smaller. I've spent countless hours debugging networking issues, IAM policies, and resource limits that would likely be simpler on other clouds. For example, setting up a private endpoint for a database in a VCN with specific security list rules took me 3 days of trial and error. But the cost savings were worth the friction.
Multi-Agent Systems: The Only Way to Scale Solo
As a solo founder, I cannot build a monolithic AI application. My approach is to build multi-agent systems where each agent is a specialized microservice. This is the only way I can manage complexity and deliver value quickly.
My typical architecture involves:
- Router Agent: A lightweight agent (often a simple Python script) that receives user input (e.g., from Telegram/WhatsApp) and routes it to the appropriate specialized agent. I use Groq for its speed for this initial routing decision, or Claude 3.5 Sonnet for more complex intent classification.
- Specialized Agents: These are focused agents, each handling a specific task. Examples:
- CRM Agent: Queries a client's CRM via API for customer data.
- Knowledge Base Agent: Performs RAG on a vector database (pgvector) for FAQs or product information.
- Booking Agent: Interacts with a booking system API.
- Human Handover Agent: Notifies a human agent via Slack or email and passes context.
- Orchestration Layer: A custom Python application (Flask/FastAPI) running on OCI Container Instances, managing agent communication, state, and logging.
- External Integrations: Telegram Bot API, WhatsApp Business API, Twilio, client-specific APIs.
This modularity allows me to iterate quickly. If a client needs a new feature, I build a new specialized agent and integrate it into the router. I don't have to refactor a large codebase. It also means I can reuse agents across different clients. The CRM agent for Client A might need minor modifications to work with Client B's CRM, but the core logic remains.
Why I Stopped Hiding the Gap
For a long time, I omitted my Deputy CEO role from my public profiles, fearing it would make me look like a dilettante in the AI space. I focused only on the technical skills I was acquiring. But the truth is, the executive experience, while not directly coding, provided a unique perspective on problem-solving, client management, and operational resilience.
It's not about what you did, but how you did it. The ability to identify a problem, break it down, allocate resources (even if those resources are just your own time), and drive it to completion is universal. My non-traditional path from Deputy CEO to solo AI developer in Panama is not a weakness; it's a differentiator. It means I understand the business context, the operational constraints, and the need for pragmatic, cost-effective solutions—not just elegant code.
Frequently Asked Questions
Q: How do you manage context and state across multiple agents in your orchestration layer?
A: I use a Redis cache for short-term conversation history and a PostgreSQL database for persistent user sessions. Each interaction includes a session_id which the orchestration layer uses to retrieve relevant context before routing to an agent.
Q: What's your strategy for handling LLM provider outages or rate limits?
A: I implement a fallback mechanism. If Groq fails or hits a rate limit, the request is automatically retried with Claude 3.5 Sonnet. This requires careful token management and cost awareness, as Claude is more expensive.
Q: How do you ensure data privacy and security for client data, especially with external LLMs?
A: I use anonymization and data minimization techniques. Sensitive PII is masked or removed before being sent to external LLMs. For highly sensitive data, I implement RAG on client-hosted vector databases within their private networks, ensuring only embeddings (not raw data) are exposed to the LLM context.
Q: What's the biggest challenge of building AI agents on Oracle Cloud Infrastructure?
A: The biggest challenge is the learning curve for OCI-specific services and the less mature developer ecosystem compared to AWS/GCP. Debugging networking and IAM issues can be time-consuming, requiring deep dives into documentation and support forums.
Top comments (0)