Everyone had opinions. Connect AI to your CRM. Use vector databases. Try this new SaaS tool. I did something different: I moved everything to Markdown files in folders. Not just my deal flow — everything. Investments, businesses I’m building, legal matters, travel planning, property management, health protocols. My entire personal and professional life, structured so that any AI tool can read it.

Thanks for reading! Subscribe for free to receive new posts and support my work.

That sounds absurd. Let me explain why it’s not.

The Mess We All Have

You know the feeling. Work stuff in Notion, documents in Google Drive, notes in Apple Notes or Obsidian, tasks in Asana or Monday, finances in a spreadsheet, emails scattered everywhere. When you want AI to actually help with any of this, you hit a wall. Upload files one at a time? Pay per API call? Build a custom integration? Set up MCP integrations? (WTF is MCP??, you might ask, and you are not alone...)

The problem isn’t the AI. It’s the data architecture. Your information is locked inside tools that were designed for humans to click through and connect, not for AI to read and process.

The Simplest Architecture That Works

Here’s what I did: I created a folder structure on my local drive, synced via Google Drive, organized by life themes — each containing projects with the same set of Markdown files.

my-system/
├── invest/    # deals, portfolio
├── build/     # ventures, products
├── work/      # Consulting
├── play/      # Travel, hobbies
├── live/      # Health, family
├── property/  # Real estate
├── legal/     # Taxes, entities
└── _system/   # Dashboard

Each project within any theme gets the same scaffold by default:

project-x/
├── CLAUDE.md        # Briefing
├── overview.md      # Context
├── workstreams.md   # Active work
├── _session-log.md  # AI log
├── _learning/       # Lessons
├── inputs/          # Working files
├── reference/       # Deep context
├── bot-work/        # Bot intel
└── vault/           # Sensitive

That’s it. Same structure whether it’s an investment deal, a property sale, a consulting engagement, or a scuba diving certification. The project type changes; the architecture doesn’t.

This is the scaffold that works for me — but there’s no single right answer. You might prefer chronological notes folders, a docs/active/archive split, or a flat structure with just a README and an AI rules file. The important thing is consistency: pick a structure, apply it to every project, and let the AI learn the pattern. You can always evolve it later. I even built a custom command that scaffolds new projects automatically — same structure every time, zero friction.

Why Markdown? Because every AI tool — Claude, GPT, Gemini, local models, whatever comes next — can read Markdown natively. No API. No connector. No MCP server. No vendor lock-in. The files are on my machine. I own them.

“But I’ll miss my dashboard / CRM view...” You don’t have to give it up. Claude Code can build a local web app — a deal tracker, a project dashboard, whatever you need — that reads directly from your Markdown files. Show it a few screenshots of your current Notion board or spreadsheet, and it generates the equivalent in an afternoon. No SaaS, no cloud, no subscription. The data stays in files; you just get a visual layer on top. If you need more structure, use .json files for tracking — AI tools read JSON natively, and Claude Code can set up any view you need on top of them.

The File That Changes Everything

The most important file is CLAUDE.md. It’s a briefing document that tells any AI: what this project is, what my role in it is, what files exist, and how to think about it.

But here’s the subtle part: it also defines a personality. A due diligence project’s CLAUDE.md might say: “Be skeptical. Flag inconsistencies aggressively.” A wellness project’s might say: “Be supportive and practical. Focus on sustainable habits.” A legal matter’s might say: “Be precise. Cite specific regulations. Challenge assumptions.” The same AI model, pointed at different folders, thinks differently.

Ten minutes writing a good CLAUDE.md saves hours of re-explaining context across sessions.

Institutional Memory That Actually Works

Each project has a _learning/ folder with three files: lessons.md, decisions.md, errors.md.

Here’s the key: every AI session checks errors.md before starting work. The system avoids past mistakes automatically. decisions.md captures not just what was decided, but why — the reasoning, the alternatives, the constraints. When a similar situation comes up months later, the context is preserved.

This works across every domain. “We chose this contractor because X, but they were late on Y — next time, ask about Z upfront.” “I passed on this deal because the unit economics didn’t hold, but if they had 3x the margin, it would change the thesis.” “The renovation went over budget because we didn’t get competing bids — next time, get three quotes minimum.”

The system literally gets smarter over time — not because the AI model improves, but because the accumulated context improves.

The Session Problem (Solved)

Most people use AI statelessly: ask a question, get an answer, start from zero next time. I solved this two ways:

Within a project: Every AI session appends to _session-log.md. Next session reads the last few entries. Instant context.

Across all projects: A session-state.md file gets rewritten at the end of each working session with: what’s in flight, recent decisions, known gotchas, and what needs attention next. Start a new session days later — even with a completely fresh AI instance — and it already knows where everything stands.

Moving Folders Is the Status Change

No CRM dropdowns. No tags. No status fields to update. A deal in _pipeline/ is being evaluated. When I invest, it moves to _portfolio/. Pass? Moves to _rejected/. Exit? Moves to _exits/. A legal matter in progress sits at the theme root; resolved, it moves to _resolved/.

The AI reads the file path and knows the lifecycle stage. And critically: _rejected/ and _resolved/ are preserved, not deleted. Those are learning data.

The Email Trick

One question that always comes up: “What about email?” I deliberately don’t connect AI to my inbox — the security surface is too large. Instead, when an email thread has genuinely useful context — a founder’s strategic response, a lawyer’s analysis, a contractor’s proposal — I save it as a PDF and drop it into the project’s vault/ or reference/ folder.

Thirty seconds of work. The AI can read it, cross-reference it with other project files, and incorporate it into analysis. But it only sees the conversations I’ve chosen to include — not every email I’ve ever received. High signal, zero risk.

The Bots: AI That Works When You Don’t

This is where it goes from “organized files” to “operating system.”

I run always-on AI agents on WhatsApp, tied to specific projects. They run 24/7 on a dedicated server. I talk to them from my phone — during calls, at dinner, on a plane. I built mine by forking an open-source project and customizing it, but there are multiple ways to set this up — each with different trade-offs in cost, complexity, and security. The specific implementation matters less than the architecture.

But bots are optional. Most of my projects don’t have one. I spin up a bot only when:

• I need to interact with a project away from my laptop

• The bot can accumulate intelligence autonomously over time

For deep work, I use Claude Code directly in the project folder. The bot is for mobility and continuous learning. The local session is for depth.

Multiple AI Tools, One Source of Truth

I don’t use just one AI tool. I regularly run sessions in ChatGPT, Gemini, or Grok to validate or challenge the analysis I build in Claude Code — especially for deep planning and important decisions. Getting a second opinion from a different model is like asking a colleague to poke holes in your thinking.

But here’s the discipline: my file system is always the single source of truth. When I finish a session in any external tool, I ask it to generate a summary — what was discussed, what we agreed on, key takeaways — as a Markdown file. I download it and save it into the project’s vault/, reference/, or _learning/ folder depending on the content. I never rely on ChatGPT’s memory or any other tool’s conversation history for continuity. My files are my system. Everything else builds on top of that.

Three Flavors of Bot

Project bots — Dedicated to one project. My investment DD bot knows only the deal I’m evaluating. My property sale bot only has the listing details and buyer negotiations. During a call with a founder: “The CEO just said ARR is $4M — does that match the data room?” The bot cross-references and replies in real time.

Theme bots — Bird’s-eye view across all projects in a theme. A pipeline bot sees every deal I’ve evaluated and passed on. Over months, it learns my patterns. An “invest” bot could flag: “This company’s profile looks similar to one you passed on — but this one has 3x the margin.” Pattern recognition that no CRM can replicate.

Infrastructure bots — System-level. A briefing bot that crawls sources and synthesizes daily intelligence. A general-purpose assistant. These serve the platform, not any single project.

The Intelligence Loop

Every bot belongs to a project. Three times a day, my laptop pulls the bot’s accumulated intelligence — research, analysis, knowledge bases, briefing summaries — into the project’s bot-work/ folder. Separately, my laptop pushes updated project context to the bot.

The loop:

1. I update project files during deep work sessions

2. Updated context syncs to the bot (3x daily)

3. Bot uses new context in its ongoing work

4. Bot’s intelligence syncs back to project folder (3x daily)

5. Next deep work session, bot intelligence is already there

When I sit down for a deep session on any project, I don’t start cold. The bot’s accumulated work is in bot-work/, structured and ready.

Security: Bots Get Packages, Not Access

The bots run on a separate machine. They cannot access my Google Drive. A manifest file explicitly lists which files each bot can see. Vault folders, stakeholder lists, personal data — excluded by default.

If the bot server is compromised, the attacker gets only the curated files I approved. The connection is one-directional: my laptop pushes to the server. The server cannot reach back.

How I Use This for Angel Investing

I’m a solo angel — no team, no analysts, no associates. Just me evaluating deals, doing DD, and monitoring a portfolio. This system is what makes that possible without drowning in spreadsheets.

My invest/ folder has four lifecycle stages: _pipeline/ (evaluating), _portfolio/ (active investments), _rejected/ and _exits/. Each deal gets the same scaffold. When a deck comes in, I create the project within the _pipeline/ folder, write the CLAUDE.md, drop the deck in inputs/, and start a Claude Code session. The AI reads the briefing and knows exactly what to do.

For active DD, I spin up a dedicated WhatsApp bot for the deal. I can interact with it during founder calls, from the airport, wherever. “The CEO just mentioned they lost their biggest client last quarter — does the revenue data reflect that?” The bot has the data room. It checks and responds in 30 seconds.

The _rejected/ folder is critical. Every passed deal stays in the system with full _learning/ notes on why I passed. Over time, this becomes a pattern library. When a new deal comes in, the AI can cross-reference against dozens of past evaluations: “You passed on two similar companies — both times because of customer concentration. This one has the same profile.”

The Bull and The Bear. For every serious deal, I set up two opposing modes: “The Bull” (make the strongest case for investing) and “The Bear” (find every reason to pass). I run both before I decide. The _learning/ folder captures both arguments and my final call. Over time, I can see patterns in my own decision-making that I’d never spot otherwise.

What I’d Build for a VC Fund

I used to work in venture capital, and left in part because the firm wasn’t eager to embrace AI. I was convinced that without AI tools, VC funds are operating with one hand tied behind their back. A year later, I’m even more convinced. If I were building this system for a multi-partner fund, I’d expand it in three ways:

1. Pipeline Bot (”The Screener”) — A theme-level bot that sees every deal in pipeline/ and _rejected/. Its job: pattern recognition across the firm’s entire decision history. “We’ve evaluated 12 developer tools in 3 years. The common thread in the passes was weak go-to-market — but this one has a VP Sales from a top enterprise company. Different profile.” This bot does pipeline hygiene too: “You haven’t touched this deal in 12 days — still active?”

2. Dedicated DD Bots per deal — Same as what I do now, but each partner has their own AI instances. Session logs are tagged by partner — instant audit trail of who analyzed what. When the deal goes to IC, all the accumulated intelligence is already structured in bot-work/.

3. Portfolio Bot (”The Board Advisor”) — Monitors all portfolio companies. Synthesizes board decks, tracks KPIs across the portfolio, spots cross-company patterns: “Three companies hiring for the same role — introduce them to the same recruiter?” Board prep becomes a conversation, not a scramble.

The _learning/ folders are shared across partners. When someone leaves the firm, their accumulated judgment doesn’t walk out the door — it’s in the files.

You get the gist...

The Real Prize: Proprietary Intelligence That Compounds

Everything above is useful at the individual level. But the real unlock — for a person or a company — happens when this becomes a long-term knowledge system. That’s when you stop having a productivity tool and start building a proprietary asset.

Here’s what I mean. Every decision you’ve ever made — why you invested, why you passed, why you hired that contractor, why you chose that vendor, why you picked that destination — contains embedded judgment. But where does it live? In your head. In email threads you’ll never find. In the memory of conversations you’ve already forgotten.

When that knowledge is structured in _learning/ folders and _rejected/ archives across every project you’ve ever worked on, it becomes queryable judgment. An AI can read across all of it and surface patterns you’d never see:

• “The last three contractors you hired through referrals worked out. The last two from marketplaces didn’t. This new one is from a marketplace.”

• “You’ve passed on three companies in this space. The underlying concern was always regulatory risk. Has the landscape changed?”

• “Your best-performing investments all had one thing in common: the founder had failed once before in an adjacent market.”

No app captures this. No CRM stores it. It only exists if you deliberately record why — not just what — and structure it so that AI can reason across the full history.

The Compounding Effect

• Phase 1: The system is a productivity tool. Sessions are faster, context carries over, bots save time.

• Phase 2: The _learning/ folders start showing patterns. You begin to see your own biases and tendencies.

• Phase 3+: You have a personal intelligence layer reflecting hundreds of decisions and years of accumulated judgment. It’s an asset that no one else has — it’s built from your specific experience, your reasoning, your mistakes.

For a company, multiply this by every employee. The firm’s collective judgment becomes queryable, preserved, and compounding. New hires onboard by reading the _learning/ folders. Institutional memory stops being tribal knowledge that walks out the door. The firm’s accumulated knowledge becomes its moat — in a world where moats are harder to find and sustain than ever.

This Works for Any Knowledge Business

The same principle applies anywhere decisions are the product: consulting firms, law practices, investment firms, PE shops, family offices, agencies. Any organization where experienced professionals make judgment calls based on pattern recognition — and where that judgment currently lives in people’s heads — can capture it in this structure.

The scaffold changes (a law firm’s project is a case, not a deal), but the architecture is identical. The competitive advantage comes from the same place: you’re turning tacit knowledge into a queryable, compounding asset.

What I’d Tell You to Do Monday Morning

1. Create one project folder with the scaffold. Pick your most active project — any domain. Create the structure. Write the CLAUDE.md. Move your working files into inputs/. Open Claude Code or ChatGPT and point it at the folder.

2. Add session continuity. After your first AI session, log what you did in _session-log.md. Next session, tell the AI to read the log first. Notice the difference.

3. Expand gradually. Add more projects. Create the dashboard.md. Start using _learning/ to capture decisions — not just what, but why.

4. Try the email trick. Next time someone sends you a substantive response, save it as PDF into the project folder. Watch how much richer the AI’s context becomes.

5. Consider a bot — only when a project is active enough to justify it. Start with one. See if the mobility + continuous learning changes how you work.

6. If you miss your dashboard, ask Claude Code to build one. Give it screenshots of what you want. You’ll have a local version in an afternoon.

7. Don’t overengineer. The entire initial setup takes a weekend. The sophistication comes from use, not from architecture.

The Punchline

The best AI data architecture in 2026 is Markdown files in folders.

Not because it’s technically sophisticated — because it’s not. Because every AI tool that exists today and every tool that will exist tomorrow can read files. Because your data stays on your machine. Because the structure makes AI dramatically cheaper and more effective. Because bots can accumulate intelligence that flows back into the same structure. And because the system gets smarter with every project you run, every decision you make, and every mistake you learn from.

AI-readiness isn’t about buying the right tool. It’s about organizing your data so any tool can work with it.

Ariel Muslera is a solo Angel and Advisor at Bluelabel Ventures, where he invests in early-stage technology companies and builds AI-powered operating infrastructure. He’s been building and iterating on this system for nearly a year. Find him at @bluelabel or bluelabel.ventures.

Want help building this for your organization? I work with a select group of investors, funds, and knowledge-driven companies to design and implement AI-native data architectures — from the initial file structure through bot deployment and the institutional knowledge layer. If this resonated and you want to explore what it would look like for your team, reach out.

If you found this useful, share it with someone who’s fighting the same data mess. And if you take this framework, run with it, and find holes or improvements — let me know. We’re all figuring this out in real time. Good luck.

Share

The venture capital model isn't just breaking down—it's actively misaligned with how the best founders want to build companies. For decades, the playbook worked: startups raised increasingly large rounds, scaled rapidly, and aimed for massive exits. But something fundamental has shifted. We're entering an era where the most successful companies might be the ones that don't follow this playbook.

Enter FAIR: Founder Aligned Investment Rights that let entrepreneurs optimize for profitability without exit pressure.

The Great Decoupling

Artificial intelligence is creating a new category of startups that can achieve remarkable outcomes with dramatically less capital. A single developer can now build products that would have required entire teams just five years ago. AI-powered automation handles everything from customer service to content creation to code generation. The result? Companies that can reach profitability faster, with smaller teams, and without the traditional venture scaling requirements.

Yet our investment structures haven't evolved to match this new reality. We're still using SAFEs and convertible notes designed for capital-intensive businesses that need multiple funding rounds before reaching profitability. This creates a fundamental misalignment: founders who could build sustainable, profitable businesses are pushed toward artificial growth and unnecessary exits because their investors need liquidity events.

The problem isn't just economic—it's psychological. Current structures force founders to optimize for the wrong metrics, hire beyond optimal efficiency, and pursue exits that might destroy long-term value. Everyone loses.

The Alignment Problem

Consider Emma, who raises $500K on a SAFE, builds an AI-powered legal research tool, and reaches $2M ARR with 80% margins within 18 months. In the traditional model, investors are now looking for the next round, the growth trajectory, the path to a $100M+ exit. But what if the optimal strategy is different? What if Emma could continue growing organically, maintain those incredible margins, and build a $10M+ annual profit machine?

Under current structures, this creates tension. Investors have no way to realize returns except through dilutive future rounds or a liquidity event. Emma faces pressure to scale beyond optimal efficiency, hire unnecessarily, or pursue exits that might not maximize long-term value.

The misalignment is structural, not personal. Good investors want founders to succeed, but SAFEs only provide one path to returns: conversion in an equity round or liquidity event. There's no mechanism for investors to benefit from sustainable profitability.

Introducing FAIR: Founder Aligned Investment Rights

FAIR documents represent a new approach designed specifically for this AI-enabled era of lean, profitable startups. The core insight is simple: create a structure that allows both founders and investors to benefit from sustainable profitability, not just exits.

Here's how founder alignment works in practice:

Dual-Track Returns: Investors receive their original investment back plus a preferred multiple (typically 2-3x) through either traditional exits or profit distributions. Once this preference is satisfied, they automatically convert to common stock or exit profit-sharing arrangements entirely.

Profit Participation: While the preference remains unsatisfied, investors receive a percentage of distributable profits (typically 20-40%). This creates immediate returns from successful, profitable operations rather than waiting years for liquidity events.

Founder Control: Unlike traditional preferred structures, founders maintain operational control throughout. Investors have limited protective provisions focused only on decisions that materially affect profitability or the ability to service the preference.

Exit Flexibility: If a traditional exit opportunity arises, the structure seamlessly handles both scenarios. Preference holders are protected, but there's no artificial pressure to pursue exits when organic growth is superior.

Conversion Certainty: Once investors have received their preference through any combination of profits and exits, they automatically convert to common stock. No ongoing preferred rights, no complex cap table management, no misaligned incentives.

A Concrete Example: How Alignment Could Work

Imagine Sarah raises $300K using FAIR documents to build an AI-powered financial planning tool. The terms include:

• 3x liquidation preference ($900K total)

• 25% profit participation until preference satisfied

• Automatic conversion to common stock once preference paid

• Founder retains full operational control throughout

Year 1: Sarah reaches $50K monthly profit. Investors receive $150K annually (25% of $600K annual profit). Remaining preference: $750K.

Year 2: Profits grow to $150K monthly. Investors receive $450K annually (25% of $1.8M). Remaining preference: $300K.

Year 3: Profits hit $200K monthly. Investors receive $300K in the first 1.5 months to satisfy remaining preference, then automatically convert to common stock.

Result: Investors got their 3x return in under 3 years plus ongoing upside as common shareholders. Sarah built a $2.4M annual profit business, maintained complete control, and never faced pressure to exit or scale artificially.

Both parties won because their incentives were aligned from day one.

Building on SAFE: Key Adaptations for FAIR

FAIR documents can leverage the proven SAFE framework while introducing profit-sharing mechanics:

Conversion Triggers: Like SAFEs, FAIR converts in equity financings, liquidity events, or dissolution events. But FAIR adds a fourth path: profit distribution mode when the company achieves sustained profitability.

Post-Money Clarity: Following SAFE's post-money structure, FAIR provides immediate ownership transparency. Investors know exactly what percentage they own and what profit share that represents.

Liquidation Priority: FAIR maintains SAFE's liquidation waterfall (junior to debt, senior to common) but adds profit distribution rights that activate before traditional liquidity events.

Conversion Mechanics: When preference is satisfied through profits, FAIR automatically converts to common stock, eliminating the complexity of managing preferred rights indefinitely.

The Ripple Effects of Founder Alignment

If FAIR documents gain adoption, they could catalyze broader changes:

Founder Behavior: More entrepreneurs will optimize for profitability over growth, leading to more sustainable businesses and better unit economics from day one. Founders can focus on building great products instead of managing investor expectations around artificial milestones.

Investor Strategy: Angels will need to develop new expertise in evaluating profitable business models rather than just scalable ones. Due diligence will focus more on margins, customer retention, and sustainable competitive advantages than just growth metrics.

Market Dynamics: We might see the emergence of "profit unicorns" - companies generating $10M+ annual profits without ever raising large rounds or pursuing exits. These businesses could become the backbone of a more sustainable startup ecosystem.

Innovation Patterns: With less pressure for massive outcomes, founders can take more creative risks and build solutions for underserved markets that might not support billion-dollar exits but can sustain highly profitable businesses.

Talent Allocation: The best founders might choose to build smaller, more profitable companies rather than managing large, capital-intensive operations. This could lead to more innovation and competition across markets.

Implementation Challenges

FAIR documents aren't without complexity. Key challenges include:

Tax Treatment: Profit distributions may complicate tax situations for both founders and investors. Clear accounting standards and tax guidance will be essential. The structure may require specific elections or entity choices to optimize tax treatment.

Definition Disputes: "Distributable profits" must be defined precisely to avoid conflicts. The framework needs clear rules about reinvestment, working capital reserves, founder salary caps, and distribution timing.

Investor Education: Many angels are accustomed to binary exit outcomes and may need time to understand the profit-sharing model. The structure requires a shift in thinking about returns, liquidity, and portfolio construction.

Follow-on Compatibility: The structure must work seamlessly with potential future rounds while protecting the economics for both parties. Traditional VCs may need education on how FAIR holders convert and participate.

Accounting Complexity: Companies will need robust financial systems to calculate and distribute profits accurately. This may require more sophisticated bookkeeping than typical early-stage startups maintain.

The Path Forward

The venture capital model will always have its place for companies that truly need massive scale. But we need complementary structures for the growing category of AI-enabled businesses that can achieve remarkable outcomes with capital efficiency.

FAIR documents represent one approach to this challenge. The key is starting with simple, standardized templates that address the most common scenarios, then iterating based on real-world usage.

What we're really building is an alternative path for entrepreneurship—one where founders can optimize for the metrics that matter (profitability, sustainability, customer value) rather than the metrics that satisfy misaligned capital structures.

The future belongs to founders who can build profitably from the start, and investors who can recognize that the biggest returns might come from sustainable businesses rather than just scalable ones. FAIR documents are designed to make both possible.

When founders and investors are truly aligned, everyone wins. The company builds better products, serves customers more effectively, and creates more value for all stakeholders. That's what FAIR really means. Welcome to the era of Seedstrapping!

The author is developing FAIR document templates and building a community of aligned investors and founders. If you're interested in participating in the early development of these structures, get in touch!

Subscribe now

Share

So… last week I decided to venture into the DJ scene.

Well… not exactly.

I decided I wanted to learn how to DJ for my wife’s upcoming birthday party (won’t say her age!). And as I usually do when I want to know something, I started by buying equipment.

That’s why I own two guitars, two bass guitars, and way more books than I’ll ever read. It’s not that I want to learn to play or read them. I just wish I already had — and I’d love to say I know how to play fluently.

Anyway…

Friday night, I dove into the amateur-DJ rabbit hole. After a few hours of YouTube tutorials — and many more (legal!) downloads from DJ music sites — I hit the first big hurdle:

🧨 The Challenge: Real Files, Real Chaos

Every DJ knows the pain. You download a fresh batch of tracks, and your folder turns into metadata hell:

01 - Rolling Stones - Satisfaction  
Adele - Someone Like You!
track_003.mp3  
Bryan Adams - 05
BACK IN BLACK - ACDC.MP3

Some filenames have artist and title reversed. Others are ALL CAPS. Some are missing genre, year, or even file extensions.

So this morning, I decided to fix it.

And by “I,” I mean: me + three Claude Code agents + one external ChatGPT advisor.

Seven minutes later, it was done.

No mockups. No fluff. Just a working CLI tool with multi-layered AI tagging, batch processing, and production-grade error handling.

⏱️ The Timeline: Git Doesn’t Lie

10:51:27 - git commit -m "feat: implement MP3Tagger AI core functionality"  
10:58:43 - git commit -m "feat: complete MP3Tagger CLI with all features"

Total build time: 7 minutes and 16 seconds.

Normally, this would be a 2–3 week project. That’s a 180x acceleration.

Of course, I also spent ~30 minutes planning (with help from my AI agents), plus another ~20 minutes testing and tweaking. Let’s call it a 1-hour Sunday morning sprint. Not bad.

🔧 The Solution: MVP but Mighty

In those 7 minutes, we shipped:

• ✅ Multi-Tier AI Processing: Mistral (local) → Claude (Anthropic) → GPT (OpenAI)

• ✅ Batch Processing: Async, scalable to thousands of files

• ✅ Checkpoint System: Resume even after a crash

• ✅ Privacy-First: Audio never leaves your machine

• ✅ Confidence Scoring: Escalate model quality only when needed

• ✅ Rich CLI Output: Progress bars, dry-run mode, summaries

• ✅ Audit Log: CSV export of every rename, tag, and fix

📁 From Chaos to Clean

Before:

track 105.mp3

Sugra - Marroon 5.MP3

daddy yankee song.mp3

Pharrell Williams - Happy!.mp3

After:

Dua Lipa - New Rules [Pop] (2017).mp3  
Maroon 5 - Sugar [Pop] (2015.mp3
Daddy Yankee - Gasolina [Reggaeton] (2004).mp3
Pharrell Williams - Happy [Pop] (2013).mp3

What started as a junk folder is now a clean, searchable, performance-ready music library.

The tool even added missing metadata like artist, album, genre, and year — all using a local (free!) LLM running directly on my laptop.

Here’s a screenshot of five original MP3s (top), and how they look after cleanup (bottom).

Note that fields like BPM, key, and length are still empty — I haven’t added audio processing yet… but that’s coming next.

🔮 What’s Next?

This was a quick prototype — a fun test that solved a real pain point. But even during the planning stage, ideas for a much bigger product started to emerge:

• 🎛️ Duplicate Detection & Storage Optimization

  Clean up alternate versions, bitrates, or duplicate tags.

• 🧠 AI-Powered Playlist Builder

  “Give me a 90s Latin dance playlist, 120–130 BPM, in minor key.”

• 🎚️ Track Intelligence Layer

  Extract BPM, key, intro/outro length, vocal presence, etc.

• 💾 Rekordbox/Serato Export

  Add cue points, color codes, and export straight into your DJ software.

• 🖼️ Cover Art & Lyrics Matching

  Automatically pull visuals and lyrics from Discogs, Genius, or Spotify.

• 🌐 Web App + Cloud Backup

  Upload your ZIP, clean it in the cloud, download a polished package.

• 🪄 Smart Setlist Suggestions

  Get recommendations based on previous gigs, tempo, or mood.

These are just starting points — but it’s clear this could evolve into a real, revenue-generating product for DJs, collectors, and music nerds like me.

The solo-preneurship era is here. Are you ready?

Share

Subscribe now

The Context

Last week I saw Tom Bilyeu's tweet about rebuilding his company in 90 days using a "5-member AI department". This idea captured something many of us have been thinking about. The vision is compelling: AI agents working 24/7, handling everything from strategy to execution, for a fraction of traditional costs.

But having spent the last month intensively building with the help of AI—not just theorizing about it—I had to respond with what I've discovered:

"This is great, but you're missing a HUGE value lever: a centralized knowledge base where context and memory is shared and updated. This also allows for convergence thinking from multiple AI profiles. It's the difference between having one-to-one sessions and a board meeting where agents can build together (plus human input). I'm actually building this and the results are remarkable."

A lot of people asked if I could share more about this approach, so this article is my attempt to show you what I mean.

The Problem with Isolated AI "Employees"

The current AI narrative focuses on replacement: replace your designer, your coder, your analyst. This approach treats AI agents like independent contractors—each working in isolation, delivering discrete outputs.

I've been testing this model extensively the past month—generating over 200,000 lines of code through rapid experimentation. Most were dead ends, but the learnings compounded quickly. While this approach works, it's fundamentally limited. At most, you get linear improvements: 1 AI + 1 AI + 1 AI = 3x better.

Often, agents start stepping on each other, creating conflicts, and you end up spending more time coordinating than coding. In many cases, I found it's actually better to just have one agent instead of many.

But what if AI agents could actually collaborate? What if they could build on each other's insights in real-time, with humans kept in the loop for key decisions?

Hierarchy Changed Everything

My breakthrough came when I stopped thinking about AI agents as equals and started organizing them like an actual company:

C-Suite Level (High-Intelligence Models)

• Strategic Advisor: Collaborates with human to set vision, identify improvement opportunities, measure ROI

• CTO: Makes architectural decisions, configures and deploys Execution Level agents based on project needs, assigns tasks to appropriate models, reviews technical work

• Framework Architect: Extracts patterns, designs methodologies, documents

• CEO: Me, the sole human!

Execution Level (Efficient Models)

• Junior Developers: Implement clearly defined tasks

• Test Writers: Create comprehensive test suites

• Documentation Writers: Keep everything current

I set up my own C-suite using multiple instances of Claude Code—the biggest advantage being they can act directly on code and are optimized for development support. I could have used other models through IDE integrations, but found it better to work with consistent terminal interfaces rather than juggling different UIs.

For the execution level, our AI-CTO helped set them up with a complexity-based routing system: simpler tasks go to cheaper models via APIs, and some even to local Ollama instances that cost nothing.

This hierarchy alone cut costs by 90%: expensive AI thinks and plans (with my inputs), efficient AI executes, expensive AI reviews and commits. Rinse and repeat.

The Infrastructure Nobody Talks About

But hierarchy is just the foundation. The real magic happens with two critical components that address what even GitHub's own Claude Code creators acknowledged as "one of the hardest problems in AI development": maintaining context across sessions and getting AI to perform consistently.

1. Agent-to-Agent Communication: Why We Chose Files Over "Proper" Protocols

With the help of my CxO suite, I built a simple asynchronous messaging system using file-based inbox/outbox folders. Before you ask: yes, we evaluated MCP protocols, N8N automation workflows, WebSocket APIs, and message queues. We chose file-based messaging intentionally.

Here's why simple beats sophisticated for AI coordination:

Reliability: APIs go down. Webhooks fail. Message brokers crash. Files just... exist. When your AI agent crashes at 2 AM, you want recovery to work without debugging connection pools or OAuth tokens.

Transparency: Every message is human-readable (and editable). No binary protocols, no authentication layers, no network debugging. Just cat inbox/message.md to see exactly what's happening between agents.

Git Integration: Messages become part of your version history. You can diff conversation threads, branch communication strategies, and roll back coordination mistakes. Try doing that with MCP or N8N workflows.

Universal Compatibility: Every programming language, every AI model, every operating system can read and write files. No SDK requirements, no API versioning, no vendor lock-in, no protocol negotiation.

Debuggable Failures: Complex systems fail in complex ways. Simple systems fail in simple ways. When our file-based system "fails," it usually means someone forgot to commit a message. When API-based systems fail, you're debugging OAuth tokens, rate limits, and network timeouts at midnight.

Zero Infrastructure: No servers to maintain, no message brokers to scale, no rate limits to manage, no automation platforms to configure. Works on localhost, works on production, works offline.

The real insight: AI agents don't need real-time messaging or complex workflow orchestration. They need reliable, transparent, debuggable communication. File-based A2A gives us exactly that.

Agents can:

• Share discoveries as they happen

• Request help when stuck

• Build on each other's work

• Maintain conversation history

It's intentionally simple—no complex APIs, no real-time coordination. Just agents leaving messages for each other.

2. Git-Based Memory and Recovery

This addresses the core problem that even the Claude Code team identified: context persistence. Instead of complex state management systems that can corrupt or fail, we use git as our single source of truth:

• Every 5-10 minutes, agents commit their work ("checkpoint")

• If an agent crashes, the next instance reads git history to recover

• Recovery takes about 45 seconds, not hours

• No complex state files or monitoring daemons

We essentially solved the "hardest problem in AI development" by using the simplest tool that could work: git, which every developer already understands. This simple approach enables recovery in under a minute, transforming what GitHub identified as a major challenge into a solved problem.

Real Results from Real Projects

In order to make this real, I am building a real product using this framework to test and improve it, spending time measuring everything on actual development tasks. Here are results from our specific context and optimal conditions:

OCR Feature Implementation:

• Traditional approach: 2 weeks

• Single AI agent estimate: 4 days (3.5x improvement)

• Our hierarchical system: 7 hours (48x improvement on this well-defined task)

Blog Post Generation:

• Traditional approach: 8 hours

• Our system: 45 minutes (10x improvement)

Test Suite Creation:

• Traditional approach: 3 days

• Our system: 4 hours (15x improvement)

Important context: These metrics apply to our specific workflow, with pre-existing patterns and clear specifications. Results will vary significantly based on project complexity and team experience, and these numbers are actually conservative based on our recent iterations.

How Convergent Thinking Actually Works

Having multiple agents with different "personalities" and experience allows for an interesting dynamic around "convergent thinking". Here's a concrete example of what "convergent thinking" looks like in practice:

The State Management Crisis:

• CTO agent was struggling with complex JSON state files that kept corrupting

• Human suggested sharing the problem with the broader agent team

• Framework Architect noticed the pattern: "We're reinventing version control"

• Strategic Advisor saw the business impact: "This complexity is killing our velocity"

• Convergent insight: "Why not just use git for state management?"

Result: We deleted our entire state management system. Recovery became nearly instant. Sometimes the best solution is elimination, not optimization.

The Patterns We've Discovered

After intensive experimentation, we've identified several key patterns:

The Challenge Pattern: One agent hits a wall → Human asks to share the problem → Another agent suggests a different approach → Breakthrough innovation

The Build Pattern: One agent discovers a useful pattern → Human suggests sharing it → Others implement variations → Systematic improvement across all work

The Vision Pattern: Human sets ambitious goal → Multiple agents explore solution paths → Convergent validation → Solutions none of us would have conceived alone

Why This Approach Actually Works

Traditional AI usage is transactional:

• Human: "Do this specific task"

• AI: "Here's the result"

• Human: "Do the next task"

Our approach is collaborative:

• Human sets vision and constraints

• Multiple specialized AIs explore the solution space

• They share discoveries and build on each other's work

• Human guides overall direction and makes key decisions

• Team uses failure and roadblocks as opportunities to collaborate and improve. As a result, system learns and improves continuously

The Cost Economics That Make It Viable

Traditional AI Team (or the approach proposed by Tom's tweet): 5 high-cost models working independently

• High coordination overhead

• Lots of wasted compute on planning

• Linear scaling

Our Hierarchical Approach: 2-3 high-cost models for strategy, 5-10 low-cost models for execution

• 90% cost reduction in our testing

• Exponential capability scaling potential

• Continuous learning and improvement

Most actual work gets done by efficient models that cost pennies per task.

Who Should Try This Approach

This hierarchical model is particularly effective for:

Development Teams ready to experiment with git-based workflows and comfortable with rapid iteration cycles.

Startups and Scale-ups that need to move fast with limited engineering resources but have well-defined feature requirements.

Product Teams working on software with extractable patterns—web apps, mobile applications, internal tools—where learnings from one feature can accelerate the next.

Technical Leaders who want to amplify their architectural vision across larger codebases without hiring proportionally more developers.

Building Your Own AI Management Team

If you want to experiment with this approach:

Start Simple

• 2-3 specialized agents with clear roles

• Basic file-based messaging between them

• Git for shared memory

• Measure collaboration, not just output

Focus on Communication

• Agents need to know what others are working on

• They need to be able to request help

• They need to share discoveries immediately

• Humans should guide when and what to share—asynchronous works better than real-time

Design for Recovery

• Everything should be recoverable from git history

• Agents should crash and restart gracefully, with full project awareness

• No complex state management systems that can corrupt

• Target sub-minute recovery times using git history

• Remember: Agents run out of memory, systems crash… the key to success is to have a very robust recovery plan for all your agents!

Measure What Matters

• How often do agents build on each other's work?

• How fast do insights propagate through the system?

• Are you seeing solutions no single agent would create?

• Is human time spent on vision or coordination?

When This Approach Works (And When It Doesn't)

This hierarchical model works best for:

• Well-defined development projects with clear specifications

• Teams comfortable with git workflows and terminal interfaces

• Projects where patterns can be extracted and reused across features

• Scenarios where iteration speed matters more than perfection

• Codebases with established architectural patterns

It's not suitable for:

• Highly creative, open-ended exploratory projects

• Teams without strong technical infrastructure comfort

• Projects requiring deep, specialized domain expertise

• Situations where explaining AI decisions is critical for compliance

• Complex debugging of legacy systems with unclear documentation

The Future We're Actually Building

We're not promising that AI will replace human developers. We're demonstrating that AI can amplify human vision in ways we're only beginning to understand.

When you create the right conditions—shared memory, diverse perspectives, structured communication—AI agents don't just work together. They start thinking together. New insights emerge that none of them (or us) would have discovered alone.

What's Next

We're building a development framework around these ideas. Current frameworks like Agile and Scrum weren't designed for AI-human collaboration—we measure development time in sessions, not sprints, because AI consistently underestimates its own speed. I will write more about this in a later post.

Our next steps involve sharing this approach with organizations ready to experiment:

• Complete documentation of our patterns

• Open-source components for A2A communication

• Frameworks for setting up hierarchical AI teams

• Measured case studies from real projects

This isn't about replacing the conversation around AI employees. It's about evolving it. The question isn't "How can I get AI to work faster?" It's "How can I build AI teams that think together?"

The difference? That's where the real leverage lives.

Want to see what hierarchical AI organizations can do for your work? We're building in public and sharing everything we learn. The future isn't about better AI—it's about better AI collaboration.

As always, if you like this, share it and follow me here or in Twitter or LinkedIn.

Share

Subscribe now

It’s not true, of course — but it feels like it might be true about AI.  

Most people are using less than 10% of what today’s AI tools can actually do.  

Not because the technology isn’t ready — but because they are stuck at the starting line.

The internet is full of advice on how to write better prompts. But that’s not what people really want.

People don’t want to become prompt engineers, they want AI that understands what they’re trying to do, remembers the context, and helps them build something real.

And when they try to go beyond the basics, they find out the hard way:  

The other 90% isn’t locked way behind better prompts. It’s locked behind a minefield of edge cases, brittle memory, broken handoffs, and duct-tape integrations.

The 10% Illusion

For most people, “using AI” means opening a chatbot and asking it to rewrite an email, summarize a document, or suggest a few ideas.

And that’s on a good day, when you don’t catch you GPT lying, pretending to do a job 10 times when you can see with your own eyes the job has not even started yet!

But the reality is that this usage of AI is like buying a supercomputer just to keep a grocery list.

Moving beyond the simple use case of prompts and chats is where things start to break even further, get even more messy, and eventually… get amazingly powerful!

What Gets Harder Than It Should Be

When I started building with AI, I thought the hardest part would be writing good prompts or picking the right model.

I was wrong.

Here’s what actually got complicated:

Memory and Continuity

When an AI chat crashes or forgets your earlier messages, you don’t just lose a response.  

You lose the whole thread of the conversation.  

It’s like talking to someone with amnesia — every time you refresh, they forget who you are, who they are, and what the hell were you two trying to accomplish. Groundhog Day vibes!

Time Doesn’t Exist

Speaking of Groundhog Day, the movie: AI tools don’t really understand “now.”  

They mix up timelines, forget what just happened, and can’t track what’s done versus what’s pending.  

Try building a workflow that depends on timing, and you’ll hit this wall immediately. Try to enforce time-triggered events, or rely on time estimates, and you are in for a big surprise…

It’s All Held Together With Duct Tape  

The deeper you go, the more you find yourself gluing tools together.  

Juggling bits of code, plugins, agents, prompts, and files — none of it obvious, and none of it stable.

The Cost is a Mystery

I touched on this subject in a previous article, but the more I get into it, the more I am amazed about how little thought it was put on pricing (or maybe a lot, because arguably the less transparent the cost, the harder to switch or compare other products).

Token-based pricing for LLM models sounds simple until you scale up. Every provider counts differently. Subscriptions hit limits, then you get charged by API usage. Estimating usage becomes a guessing game. It is a nightmare.

You’re not paying for outcomes — you’re paying for words generated during the attempt.

The good news is: no matter how much you use these models, you will end up paying less than what you spend on your daily Starbucks run.

AI isn’t magic. It’s a stack.

To get serious about using AI, you need more than clever questions.  

You need a system — a stack of components that work together.

Here’s what that may look like:

• Conversation Layer: Keeps the chat smooth and coherent  

• Task Manager: Passes tasks between agents, retries if needed  

• Memory Keeper: Stores context, recalls what's important  

• Smart Tool Picker: Chooses the best AI model for each job  

• Debugging Layer: Logs issues, helps trace failures  

• Glue Code: Holds it all together behind the scenes

Most of this? You have to build or duct-tape together yourself.  

That’s the price of going beyond 10%.

What Actually Gets Easier

Ironically, the things I worried about most turned out to be easy:

- Spinning up simple AI helpers? Done in a weekend.

- Switching between different AIs? Not hard at all.

- Building a basic UI? The AI can help with that.

- Writing code with little experience? Surprisingly doable.

But the moment you care about keeping track of things, working at scale, or handing off tasks reliably, you’re in infrastructure territory.

That’s where most people give up. That’s where the real value comes, too.

The Big Payoff

But if you push past the 10% mark — even just to 50% — something wild happens: You unlock a space where entirely new things become possible.

Just like Google Ads unlocked long-tail marketing, and YouTube empowered a generation of content creators, agentic AI — AI that can take actions and make decisions on your behalf — is about to unlock the long-tail builder economy.

You won’t need to be a developer to:

- Launch a micro-business

- Automate your personal and professional operations

- Invent niche services that were never economically viable before

Not because you learned to code — but because you learned how to stack, route, and delegate. Or someone else solved this for you… :P

What I’m Building Now

I’ve been deep into AI coding for almost a month now. With my limited coding expertise, my agents and I wrote well over 100,000 lines of code and multiple projects. Some of them failed. Actually, most of them failed. But in that process, I learned, I iterated, I understood what worked and what didn’t. I got to create my own system of agents that collaborate. I changed AI models, I screamed at the screen more than I would like to recognize. I also pulled more all-nighters than ever in my life. Not because my boss was pressuring me, but because I got addicted and excited about the possibilities.

I now know that the next wave of innovation will be the long-tail, AI-first builder economy, and that’s where I’m headed next:

I’m building tools, templates, and systems to help anyone go beyond the 10% — and reach the real power of AI, to help people:

• Translate their needs and pains into product

• Design their own AI workflows

• Launch small, leveraged businesses

• Become creators — not just of content, but of software and systems

We’ve had the creator economy.  

Now we’re entering the builder economy.

And yes — it’s going to be weird, messy, and magical.  

But it’s going to be more accessible than anything that came before.

What a time to be building.

Stay tuned!

Hit a minefield building with AI? Or just curious what 50%+ workflows look like? I’d love to hear from you.

As always, share this article if you liked it, follow me on Twitter, comment below… do your thing. Thanks!!

Subscribe now

Share

Into the AI Rabbit Hole

I left my role as a Partner at Borderless Capital to explore a big question: What would it look like to build an AI-powered platform for early-stage investing?

I wasn't sure where the experiment would lead — and I'm still not — but I dove in headfirst.

Armed with coding assistants like Cursor, Windsurf, and Claude Code, and with ChatGPT as my tutor and sounding board, I began building. I'm not a developer, but I figured I could learn enough to ship.

The project was ambitious: A multi-agent system to process content, analyze investments, and assist with deal flow — the kind of platform you'd normally need a full team to build.

But I had none. Just me, a few powerful AI models, and a lot of determination.

Then the Lightbulb Went Off

One Sunday, after days of bouncing between assistants, it hit me:

What if I just… hired them?

I opened a new thread with ChatGPT and said:

"You're now my CTO. We have three engineers: one handles front end, one owns the back end, and one takes care of general dev and documentation. Let's run a sprint."

It took about an hour to set up the context and role definitions. And then?

Boom. Productivity tripled.

Tasks ran in parallel. I was suddenly managing a full-stack AI dev team — no hiring, no equity, no HR overhead.

Within days, I had built:

• A working content processing system that could analyze articles, PDFs, and audio files

• Smart routing between different AI models based on task complexity

• An agent architecture that could coordinate multiple specialized functions

• A user interface that let me monitor and control the entire system

More than I thought possible as a solo founder with no formal development background.

The Orchestrator Epiphany

For a few days, I was thrilled. The dream was working.

But then I noticed something:

I had become the bottleneck.

I was spending hours copy-pasting outputs, translating requirements, and directing traffic between assistants like a 1960s switchboard operator.

If one agent gave me 1x leverage… and three gave me 3x… Why was I still doing all the coordination manually?

That's when it clicked: I didn't just need AI workers. I needed an AI manager.

So I built it — an orchestration layer that manages AI agents autonomously.

The result? A system that now runs complex workflows while I sleep.

I started calling this "The AI-Burger Stack" because the structure is like a burger: human+AI interaction to handle strategic planning (the top bun) and review outcomes (the bottom bun). Everything in the middle runs autonomously. The AI Manager orchestrates the dev team, they coordinate amongst themselves, and I only step in again for critical decisions or scope changes.

Here's how I think about the stack:

Most people think building with AI means "using a model."
But real leverage comes when you design a system:

🍔 Top bun: Strategic planning and intent
🧠 Patty: An AI manager that orchestrates execution
🍅🥬 Fillings: Specialized AI agents doing the work
🔄 Secret Sauce: Communication and sync logic
🍞 Bottom bun: Review, learning, and iteration

Everyone's using the same ingredients.
What matters is how you stack them.

The Bigger Shift: Service as Software

The deeper I go, the more it becomes clear:

This isn't just about making work faster or cheaper. It's about rethinking what work even is when software doesn't just assist — it executes.

We're moving from:

• Software-as-a-Service → Service-as-Software

• Tools that help → Systems that deliver

• Dashboards to check → Outcomes that arrive

Let's make it real with a few examples:

Old fundraising model: You spend weeks refining your deck, scouring LinkedIn for warm intros, crafting outreach emails, and chasing down meetings — one at a time.

New fundraising model: You say, "I want to raise a Series A." The system researches your market, refines your pitch, identifies aligned investors, drafts personalized outreach, books meetings, and fills your calendar — complete with tailored talking points.

Old content creation: You hire writers, editors, and strategists to produce a steady stream of thought leadership content.

New content creation: Your AI team analyzes your expertise, monitors industry conversations, drafts articles in your voice, and publishes across channels while you focus on high-level strategy.

Old market research: You hire analysts to track competitors, monitor trends, and compile quarterly reports.

New market research: Your system continuously scans 100+ sources, identifies emerging opportunities, maps competitive movements, and alerts you to actionable insights in real-time.

That's not productivity software. That's execution infrastructure.

What This Means for Founders

If you're an early-stage founder, this changes everything.

The leverage equation has shifted. With the right AI orchestration, a solo founder can now execute at the level of a small team — across development, content, operations, research, and more.

The bottlenecks aren't capital or capability anymore. They're imagination and coordination.

You don't need to hire faster. You need to think differently about what "a team" even is.

What This Means for Investors

For VCs, this creates both massive opportunity — and existential questions.

The opportunity: Startups can validate, build, and scale faster and cheaper than ever. Time from idea to traction is collapsing.

The questions:

• If a solo founder can execute like a team, how do we value human capital?

• What happens to hiring patterns, burn rates, and equity allocations?

• How do we assess teams when AI can fill entire functional roles?

• What business models become viable when the marginal cost of execution approaches zero?

We're no longer just funding teams. We're funding human-AI hybrid organizations where the leverage is unprecedented.

But here's the thing: This shift doesn't just apply to the companies we invest in. It applies even more to those of us on the financing side. If you want to get alpha as an investor, you need an AI toolset. Not just ChatGPT. You need an AI extension of your team — highly specialized, highly leveraged. That's exactly what I'm exploring now: how to build that investor-focused AI orchestration system.

The Mindset Shift

Here's what I've learned in two weeks:

We're not in the "AI tools" era anymore. We're in the AI teammates era.

The winners won't be those with the best features. They'll be the ones who orchestrate AI systems that deliver complete outcomes.

It's like the difference between selling hammers… and building skyscrapers.

Everyone's focused on better tools. The opportunity is in how we build with them.

That means:

Stop asking, "Who should I hire?"
Start asking, "What outcomes do I want to achieve — and how can AI help me deliver them?"

Stop thinking in org charts.
Start thinking in workflows and outcomes.

Stop worrying about replacing humans.
Start focusing on amplifying judgment, creativity, and execution velocity.

AI is Happening, Faster than You Realize

I'm not alone in seeing this shift. Founders across industries are discovering they can now execute ideas that felt impossible just months ago.

This changes how we:

• Build companies

• Think about moats

• Price services

• Structure teams

• Evaluate and execute investments

We're not on the edge of a productivity revolution. We're in it.

The question isn't if this changes everything. The question is: Are you ready to rethink how you work?

Up Next

In my next post, I'll share:

• Real examples of AI orchestration I'm seeing across different industries

• The specific agent workflows I've built and how they collaborate

• My predictions for how this reshapes venture investing in 2025

• Why I think we're heading toward "AI-native" companies that operate fundamentally differently

Let's Connect

If you're a founder experimenting with AI orchestration, an investor thinking about these shifts, or just someone fascinated by where this is all heading — I'd love to connect.

I'm particularly interested in talking with:

• VCs who are starting to implement agents and other advanced AI-native tools in their daily workflows

• Founders who are building with agent architectures

• Operators who are rethinking traditional org structures

As always, share this content in your social networks if you like it, subscribe if you still haven’t, and follow me in Twitter/X or LinkedIn. Let's figure out this new world together.

One agent at a time.

One week into building Bluelabel AIOS — my AI-first investment productivity platform — and I’ve already rewritten half my architecture, tested 12+ tools, thought about writing a whitepaper on pricing models, and briefly fantasized about launching a full-blown AI studio. Oh, and I found myself constantly saving content to my “read later” WhatsApp channel.

It’s been overwhelming, addictive, and more energizing than anything I’ve done in years.

This post is a snapshot of the first week: what I built, what surprised me, where I got stuck, and where I think this is going.

Vibe coding is real — and it’s addictive

I’ve spent more time inside Cursor, Claude Code, and LLM-powered terminals this week than I expected — and I loved it.

I feel I cheated on my old friend ChatGPT (sorry!), though I still used it to polish things up and help me decide on tools and architecture for the project.

Even with zero Python experience, I was able to spin up real, working agents and iterate fast. The tools are that powerful.

It wasn’t always smooth (more on that below), but I got lost in the kind of creative flow that only happens when the gap between idea and execution disappears. That’s the magic of vibe coding — and now I’m hooked.

You need more than one model (and interface)

As I started experimenting, I quicky realized you can’t rely on just one model or interface. Running the same prompt through ChatGPT Plus ($20/mo), Claude.ai, Claude Code, and Cursor often gave totally different outcomes.

Here’s how I approached it:

• Early in the week, I used Claude.ai as a step-by-step guide, then pasted scripts into Cursor.

• As I felt more comfortable, I upgraded Cursor’s IDE subscription to Cursor Pro ($192/yr), letting its AI agent act as my copilot (he was the pilot, actually, and I wasn’t even the copilot: I was sitting comfortably in the back seat!). Cursor worked really well for deep iteration with memory directly on my code, but I found it entering in loops often.

• By midweek, I upgraded to Claude Max ($100/mo, includes Claude Code + API tokens), which was better at reasoning and executing in code, and I ended up constantly coming back and forth from Cursor to Claude Code. This proved to be a good strategy to get out of infinite loops or fine solutions when one of them got stuck.

• ChatGPT? Still great for structure and non-code tasks, but for some reason I didn’t think it would do as good a job as the rest in coding.

The bottom line: treat models and tools like instruments in a band, not a single solo player.

Tokens (the AI pricing kind) are a mess

Coming from Web3, the word “token” instantly triggered a flashback to utility tokens, ICO mechanics, and reward loops.

AI tokens — as in compute cost — aren’t all that different. They’re abstract, often poorly explained, and vary wildly depending on the provider and interface. At least the Gary Gensler is not all over them (bad joke for my Web3 followers).

I had to stop myself from going full whitepaper-mode and mapping out a tokenomics strategy for prompt-based workflows, but I actually think the idea of using a crypto token model for AI pricing is not as crazy as it sounds. Maybe next week I write more about this idea…

Real talk: if you’re building with LLMs, expect to spend $100–200/month just to explore seriously (Right now I am spending close to $200). Hosting and infra not included. But hey — that’s less than feeding one developer in pizza, and this one never gets sick or pushes back on crazy ideas. (Although let’s be honest: no dev has ever said “no” to a wild idea — they just say it’ll take two weeks.)

Sometimes, the best fix Is a reset

Vibe coding spoils you.

So when I hit bugs or looped endlessly in Cursor or Claude Code, I got frustrated — until I remembered: I’m programming in a language I didn’t know last week.

That’s insane.

So instead of debugging forever, I laughed, threw out the broken code, and started fresh.

What helped:

• Accepting that AI-native workflows are messy by nature

• Using version control and writing changelogs (even if just for myself)

• Letting the agents read those changelogs to get better and understand what I was building

Lesson learned: don’t debug forever. Back out, reset, and re-vibe. It is not that you will be writing the code from scratch anyway…

Infrastructure first, features second

I knew that before I could scale to the 100+ agent vision, I had to set the right foundations.

This week was all about:

• Getting consistent folder and file structures

• Defining configs and prompts clearly

• Researching about AI dev tools, including MCPs (Multi-Component Prompting), which feel like the REST API equivalent for agents

• Doing and undoing a lot of architectural / tech stack decisions as I learned more about things

Last week was definitely not about coming up with a beautiful UI/UX. Hopefully, next week I make a bit of progress there.

The chat interfaces are amazing… until they aren’t

ChatGPT and Claude.ai are fantastic for learning and iterating, but once you need:

• File system access

• Long context windows

• GitHub workflows

• Persistent memory

…they hit their limits fast.

Initially, I was copy/pasting everything from Claude.ai into the Cursor IDE, and that helped me gain confidence because it felt like I was writing the code (I was not!), but soon I needed tools that could read/write directly from code files and keep track of the latest changes without me having to explain the changes first. That’s where IDE-based tools like Cursor’s internal AI agents and Claude Code’s terminal became essential.

Speaking of my new friend Claude Code, I wish it had a more robust UI — the minimalism is clean, but sometimes it’s too abstract.

Some coding background helps — but it’s not required

I had never touched Python before this week.

But my past full-stack bootcamp (which included some JavaScript and Node.js) saved me. I knew just enough to spot a broken variable or misaligned function.

That said, you don’t need to be a dev — but it helps to understand how systems behave: files, dependencies, logic flow.

And remember that LLMs will happily walk you through almost anything. Just try not to say “please” or “thank you” each time, it costs ChatGPT millions!!

Vibe designing and “frontend first” thinking

I started this project from the backend — because it felt natural. Build the foundation first, then work on the exterior.

The result is that my UI sucks, and I ended up having quite a bit of issues with the frameworks recommended by Cursor and Claude (Streamlit and Flask).

In fact, after doing some research, I found that frontend first might also be a good approach — especially for LLM-native tools: The concept of vibe designing focuses on building the user experience first, often in collaboration with AI, and letting that guide the architecture. Is the designers answer to the nerd’s vibe coding.

The battle is on!

Tools like Bolt.new, PRDKit, and UXPilot.ai are interesting early signals in this space. Next week, I may build a UI prototype first and work backwards — just to test the contrast. If I do, I will report back in a future post. In the meantime, here’s a screenshot of the current UI (yes, I know, no bueno!):

Main lesson of the week: try this at home

If you're curious, the best way to understand any of this is to get your hands dirty. A few good places to start:

• Cursor – AI-native IDE

• Claude Code – minimalistic terminal + assistant

• Ollama – local LLM runner

• Streamlit and Flask – quick UIs for Python

• Perplexity – fast, citation-rich research

• ChatGPT – Of course, I cannot forget about my first love in AI… still rocking.

If you still don’t know where to start, just search for “vibe coding” in YouTube. But my recommendation is to download some of these tools and start with a simple prompt and go from there. You’ll be surprised how far you get.

My plan for next week:

• I want to finish the infra, including a robust local LLM system so I can start training it to become a “mini me” and help me with my investor workflow: I ordered a high-end Mac Mini to start testing local LLM deployment, but it arrives next week. Can’t wait to get my hands on it — more on that in a future post.

• I’m evaluating Vercel, Cloudflare Pages, and other options for a lightweight web deployment.

• The goal is to launch a working MVP version of Bluelabel AIOS soon, and offer early access to a small circle of founders and operators to get real feedback.

Can’t wait to share what that looks like.

One more thing…

The post I published last week sparked something unexpected:
A wave of conversations with other founders and VCs — many in their 40s and 50s — who told me they felt exactly what I described:

“This changes everything.”
“I’ve never felt the ground move like this before.”

I’ll share more about those conversations — and where I think this is all heading — in my next post.

Cheers!

PS: If you like this content, please share in your socials!

The Cracks Were Already Showing

Venture capital didn't break overnight. The model has been quietly misfiring for years.

Fund sizes ballooning from $50M to $500M+. Exit timelines stretching from 5 years to 10+. LPs still asking for 3x net returns, but most funds quietly optimizing for assets under management and 2% management fees—not the 20% carry that would align them with founder and LP success.

Even in Web3—an ecosystem that promised to reinvent venture—familiar patterns took hold. Startups were pushed to launch tokens they didn't need. Token warrant structures padded investor returns but damaged community trust. Tokenomics became a tool to satisfy cap table math, not ecosystem design.

Meanwhile, secondaries became a pressure-release valve—not because the system was working, but because liquidity had vanished. IPOs are down 80% from 2021. Acquisitions are increasingly rare. The market for exits has evaporated.

The model wasn't dead yet. But it was definitely sick.

Along Came AI

And that changed everything.

In 2000, I helped launch a startup that raised a $19M seed round—half of it went to servers. A few years later, AWS made that infrastructure obsolete and ushered in the Web 2.0 era.

Now we're at another inflection point, but this one is 100x faster and more consequential for the venture industry:

AI is rewriting the startup playbook. Small teams can go from idea to product-market fit in months—not years—using off-the-shelf tools that cost just a few hundred dollars a month. What once required dozens of engineers and millions in capital now requires only speed and vision.

I recently spoke with a founder who built, launched, and hit $50K in MRR within 90 days—solo, with no outside funding, using tools that didn't exist a year ago. This isn't an edge case anymore. It's becoming the norm.

Founders today are optimizing for speed, ownership, and optionality. Venture is still optimizing for check size, ownership, and 10x exits.

Worse, most funds aren't prepared and are facing a typical innovator's dilemma: while AI is eroding their edge in sourcing, diligence, and support, adapting would mean dismantling the very business model—predictable, fee-based, and risk-free—that keeps them alive. That's why many VCs pretend that AI will not come after their business. They are wrong…

A Time for Change

In the last few months, I started asking myself some hard questions:

Do I still believe in the way venture works today?

Would I be comfortable leading a 7-year closed-end fund in a world where cycles are compressing this fast and where incentives are so misaligned?

What kind of investor do I want to be in the AI era?

After decades investing through traditional venture, and after nearly a year as a Partner at a leading Web3 Venture fund, I decided to step away from traditional venture models to focus on building something new.

Not out of frustration or burnout.

But because the gap between what founders need and what traditional VC offers is widening by the day. And I no longer felt that retrofitting a model I no longer believed in was something that I could do.

What I'm Building Instead

Today, I'm launching Bluelabel.Ventures — not just a fund, but a flexible, independent platform for early-stage investing in the AI era.

It's early. It's experimental. But it will be built for the world that's coming instead of the one we used to live in. Some guiding principles are:

Independent
No LPs. No committees. I will move fast, invest my own capital, and stay close to founders. When a deal makes sense, I can say yes in days, not weeks. When it doesn’t, I will try to provide valuable feedback and not waste founders’ time.

Structure-Agnostic
I'm planning to test new funding and partnership models: rev-share deals where founders keep 100% equity, founder buybacks with flexible timelines, equity/token hybrids optimized for community health—whatever fits the company's actual trajectory, not just my fund's.

AI-Enhanced
I plan to use AI across sourcing, diligence, and portfolio support—not to replace judgment, but to scale my capacity. I already started building what I call Bluelabel OS, a series of agents that can help me do the work of a traditional 3-person investment team, and I plan to add new features and functionalities that can also benefit my portfolio companies (more on this soon).

Aligned & Collaborative
I'm not chasing unicorns. I want to back teams building meaningful, sustainable businesses. At the end of the day, return is not just IRR. I want to have fun and be proud about the portfolio I create. I also want to learn new stuff and work with people I trust and admire. This is my measurement of success.

What I'll Be Sharing

This is a hands-on experiment. But while I dust off my coding skills (vibe coding, as they call it now, hehe!), I plan to also share my experience and thoughts, posting about:

• How I'm leveraging AI to run a solo operation that competes with larger firms

• Why most VCs are stuck in the pre-AI paradigm—and what needs to change

• What AI is (and isn't) changing in venture decision-making

• Interesting ideas and examples of AI applications I find while experimenting

• Real numbers behind alternative deal structures I'm testing

• And, occasionally, notes on scuba diving, books, and other random thoughts

Join Me and the Bluelabel Ventures Community

If you've read this far, you're likely feeling the same tension I am—between how venture has worked and how it needs to work in the AI era.

I'm building Bluelabel Ventures not just as an investment platform, but as a community for those interested in how to reimagine early-stage funding and startup building in an era of ubiquitous AI. Here's how to get involved:

For Founders:

• Subscribe to the Bluelabel.Ventures Substack for frequent insights on AI-era company building

• Share your experiences using AI, tell me what tools you'd like to have and can't find

• Connect on LinkedIn or DM me on X @bluelabel with "Founder Chat" if you're building something aligned with my thesis

For Investors & Industry Observers:

• Share your own experiences with what's working/breaking in traditional venture

• Tell me about your own experience using AI for investing, or reply to any Substack post with questions about AI's impact on investing you'd like me to address

• Suggest topics for upcoming deep-dives or podcast conversations via email (hello@bluelabel.ventures)

I'll be sharing new frameworks, data, and case studies from the frontlines of this transition. No fluff, just practical insights you can apply immediately.

The old playbooks are becoming obsolete. Let's write the new ones together.

🔹 Subscribe to Bluelabel Ventures Substack
🔹 Follow on X: @bluelabel
🔹 Connect on LinkedIn

Ad astra. 🤖🚀🤖