The Agento Suite: Building 6 AI Products in Parallel

People think I'm crazy when I tell them I'm building six products at the same time.

PowerAgento. TravelAgento. CodeAgento. LegalAgento. MedAgento. Bocads. Six products, six industries, one engineering team of one.

The reasonable thing to do would be to pick one, focus on it, and build it to maturity before moving to the next. That's what every startup advisor, every VC, every business book says. Focus. Say no. Do one thing well.

I've done that. For eighteen years with Aviation Infinity. For seven years with ClickAi. I know what focus looks like.

Building six products in parallel is a different strategy, and it only works under very specific conditions. This article is about what those conditions are, why I chose this path, and the engineering architecture that makes it possible.

Why Parallel, Why Now

The decision to build in parallel wasn't impulsive. It was the result of a specific observation:

The same AI infrastructure solves fundamentally different problems depending on the domain layer you put on top of it.

Every Agento product needs the same core capabilities:

• User authentication and account management
• Payment processing and subscription billing
• AI-powered content generation and conversation
• Document creation and management
• Search, matching, and recommendation
• Admin dashboards and analytics
• Email notifications and transactional messaging
• API integrations with third-party services

The difference between LegalAgento and TravelAgento isn't the technology stack. It's the domain model. Legal has attorneys, practice areas, jurisdictions, trust accounts, and bar compliance. Travel has destinations, itineraries, hotels, flights, and booking confirmations.

If you build the shared infrastructure once and make the domain layer swappable, the marginal cost of the next product drops dramatically.

The Shared Platform Architecture

Every Agento product runs on the same foundation. Here's what's shared:

Authentication layer. One auth system handles sign-up, login, OAuth, session management, and role-based access control across all products. A user who has a PowerAgento account can use the same credentials for TravelAgento. The system knows which products they've activated and what permissions they have.

AI orchestration engine. This is the core. A unified system that handles prompt construction, model selection, context management, response streaming, and output validation. Each product defines its own prompt templates and domain constraints, but the orchestration logic is shared.

When LegalAgento needs to generate a demand letter, it calls the same engine that TravelAgento uses to generate an itinerary. The engine handles the model call, the streaming, the retry logic, and the output formatting. The domain-specific layer handles the legal language, the jurisdictional requirements, and the document template.

Payment and billing. One Stripe integration handles subscriptions, one-time payments, metered billing, and invoicing for all products. Each product defines its pricing tiers and billing events, but the payment infrastructure is identical.

Document pipeline. Legal documents, travel itineraries, business plans, ad creatives: they're all documents. The pipeline handles generation, templating, PDF export, versioning, and storage. Each product defines its own templates and output formats.

Notification system. Email, in-app notifications, and webhooks run on one system. Each product defines its triggers and templates.

Admin and analytics. One admin framework powers the dashboards for all products. Usage metrics, user management, content moderation, billing administration: the UI components are shared, the data sources are product-specific.

This isn't a monolith. Each product has its own frontend, its own domain models, and its own deployment. But they share a common services layer that handles everything that isn't domain-specific.

The Domain Layer: Where Products Diverge

The shared infrastructure handles maybe 60% of each product. The remaining 40% is pure domain logic, and that's where the products become genuinely different.

LegalAgento needs to understand unbundled legal services, the concept that a client can hire an attorney for a specific, limited task rather than full representation. It needs to match clients with attorneys based on practice area, jurisdiction, and availability. It needs to handle trust account compliance. It needs to ensure the AI never crosses the line into unauthorized practice of law.

TravelAgento needs real-time availability from hotel and flight APIs. It needs to understand travel preferences: budget vs. luxury, adventure vs. relaxation, family vs. solo. It needs to handle multi-city itineraries with logical routing. It needs integration with hotel and booking partners.

MedAgento needs to manage patient records with proper access controls and audit trails. It needs scheduling that understands appointment types, provider availability, and room allocation. It needs prescription management with drug interaction checking. It needs billing codes and insurance claim workflows.

PowerAgento needs to generate coherent business plans from minimal input. It needs financial modeling that produces investor-ready projections. It needs pitch deck generation that follows established storytelling frameworks. It needs to understand startup terminology and investor expectations.

CodeAgento needs to integrate with GitHub, understand repository structure, and generate code that actually compiles and runs. It needs to handle multiple programming languages and frameworks. It needs deployment pipelines to AWS and Vercel. It needs code review and security scanning.

Bocads needs to understand advertising formats across Facebook, Instagram, TikTok, and Google. It needs to generate creative assets (copy, headlines, descriptions) that fit each platform's character limits and best practices. It needs A/B variant generation and performance optimization.

Each of these domain layers took weeks to build. But without the shared infrastructure, each would have taken months.

The Reuse Math

Here's the math that makes parallel building work.

Building the first Agento product (LegalAgento) took roughly 12 weeks:

• 7 weeks on shared infrastructure (auth, payments, AI engine, documents, admin)
• 5 weeks on domain-specific logic (legal matching, compliance, attorney dashboards)

Building the second product (TravelAgento) took roughly 6 weeks:

• 1 week adapting shared infrastructure (minor extensions)
• 5 weeks on domain-specific logic (travel APIs, itinerary generation, booking flow)

By the fourth product, it was closer to 4 weeks, almost entirely domain work.

The shared infrastructure amortizes across every product. And it keeps improving: a performance optimization to the AI engine benefits all six products simultaneously. A security patch to the auth system protects all six products at once.

This is the compound advantage of building on a shared platform. The more products you build, the better the foundation gets, and the faster each subsequent product ships.

What Goes Wrong

Building in parallel isn't free. There are real costs and real risks.

Context switching is expensive. Even with shared infrastructure, each product has its own domain logic, its own users, and its own bugs. Switching between legal compliance rules and travel API integrations requires mental gear changes. I mitigate this by batching work, spending full days on one product rather than switching hourly.

Support scales linearly. Shared infrastructure reduces engineering time, but it doesn't reduce support time. Each product has its own users with their own questions. Six products means six support channels. This is the first thing that will need a team as the products grow.

Quality risk. The temptation to cut corners is real when you're building six things. "Good enough" becomes the default. I fight this by having a hard rule: each product must work as well as if it were the only product. No excuses about being spread thin. Users don't know or care that five other products share the same engineer.

Market attention is divided. Marketing one product is hard enough. Marketing six simultaneously is nearly impossible. My current strategy is sequential launches, bringing products to market one at a time while the others continue development. LegalAgento launched first. The others follow.

Why Not Build One Platform?

The obvious question: why not build one platform that does everything?

Because that's how you build something that does nothing well.

A platform that handles legal services, travel planning, healthcare management, startup tools, and code generation would be so broad that no user could understand what it's for. The marketing would be impossible. The onboarding would be confusing. The feature set would be a compromise in every direction.

Separate products with shared infrastructure gives you the engineering efficiency of a platform with the market clarity of focused products. Each Agento product has its own brand, its own landing page, its own onboarding, and its own value proposition. Users of LegalAgento never see TravelAgento unless they want to.

The shared infrastructure is invisible to users. It's an engineering decision, not a product decision.

The Playbook

If you're considering building multiple products in parallel, here are the prerequisites:

You need 10+ years of building experience. This isn't a strategy for your first product. You need to have built the same systems (auth, payments, search, admin) so many times that you can do it in your sleep. The speed advantage comes from pattern recognition, not from working harder.

You need a genuine shared infrastructure layer. Not "we'll extract shared code later." The shared layer needs to be designed from day one as a multi-product foundation. Extraction after the fact is a refactoring nightmare.

You need domain knowledge in each vertical. You can't build for legal without understanding legal. You can't build for healthcare without understanding healthcare. Either you have the domain knowledge yourself, or you have advisors who do. Generic AI products for regulated industries will fail.

You need to be honest about capacity. Six products from one person means six products that ship slower than one product from one person. The math works because of shared infrastructure, but it doesn't eliminate the constraint. If any single product needs to be world-class by next month, don't build in parallel.

You need a sequential go-to-market strategy. Build in parallel, launch in sequence. Trying to market six products simultaneously is a recipe for marketing none of them effectively.

What's Next

The Agento suite is still early. LegalAgento is live. The others are in various stages of development and beta testing.

The long-term vision is a family of AI-powered platforms, each the best in its vertical, all running on shared infrastructure that improves with every product added. When a model upgrade improves the AI engine, every Agento product gets better overnight. When a new payment feature ships, every product gets it for free.

It's an unusual strategy. But eighteen years of building products taught me that the conventional path isn't always the right one. Sometimes the best move is to build six things at once, if you've spent nearly two decades learning how.