An investment memo on building the multi-SaaS coordination layer for autonomous agents.
The AI-Native Discovery Engine is a platform that enables autonomous AI agents to discover, evaluate, and orchestrate workflows across fragmented SaaS environments without manual integration or configuration. Rather than hard-coding connectors to Slack, Salesforce, and HubSpot, agents ask the platform: "What tools can help me reach a prospect?" and it returns ranked options (email, LinkedIn, SMS, Zapier) with access metadata, rate limits, and cost estimates.
The core product is an agent-facing API that:
The bottleneck in multi-tenant AI agents is not the LLM, the orchestration layer, or compute. It is the impedance mismatch between agent intent ("find 50 prospects, enrich their profiles, send outreach") and the reality of 50+ incompatible SaaS APIs, auth schemes, and usage tiers.
Today, every agent platform hard-codes integrations: Vapi handles Twilio and Voicemail, TivAI handles voice + Zapier, Sales Connector handles Stripe + email. Each integration takes 2-4 weeks. Each deprecation or schema change breaks the platform. Each new customer type (healthcare, manufacturing, B2B legal) requires new connectors.
An AI-Native Discovery Engine inverts this. Instead of predicting which tools customers will use and building connectors to them, the platform asks agents: "What would you do if you could access ANY tool?" and then dynamically wires the best match at runtime.
This unlocks three value levers:
A simple MVP ("the agent can query Salesforce and send email") sounds reasonable but fails at the complexity threshold. Here is why:
Discovery is non-trivial. A customer's workspace has 15+ SaaS accounts across dev, staging, and prod, many with partial permissions. An agent that blindly tries to use all of them will corrupt data, fail silently, or waste quota. Discovery must be intelligent: understanding which instance is authoritative, which require backfilling before use, which are read-only.
Routing is an optimization problem. Given 3 ways to send an SMS (Twilio direct, Zapier SMS, HubSpot SMS via Twilio), the agent needs to pick the one that minimizes latency, cost, and failure rate under the current quota state. This is not a lookup table; it changes hourly as billing resets or limits are hit.
Observability scales linearly with complexity. When an agent's outreach campaign fails to reach 200 people, operators need to know: did Zapier rate-limit, or did the email service reject bad domains, or did we lack permission to write to Salesforce? Without signal aggregation across 50+ API surfaces, debugging becomes a guessing game.
Schema ownership is a governance problem. Every SaaS API evolves. Slack deprecated OAuth scopes, Stripe split resources into products, HubSpot renamed fields. A monolithic integration breaks on each change. A discovery-driven system can quarantine broken paths, suggest alternatives, and notify operators - without code deploys.
An MVP that hard-codes 3 integrations looks polished. But it's a 2-month engineering dead-end the moment a customer asks: "Can you also use our Klaviyo account?"
Build true connectors (not Zapier) for the top 10 by market cap (Salesforce, HubSpot, Slack, Google Workspace, AWS, Stripe, Twilio, Shopify, Databricks, Notion). Invest in LLM-driven schema inspection to auto-catalog capabilities. Build a simple agent-facing API that routes requests and handles common auth flows (OAuth2, API keys, basic auth).
Collect agent usage logs: which tools are called together, which fail, which are slow. Build a lightweight ML pipeline (not deep learning; simple heuristics) to predict best route based on agent intent and workspace state. Add cost estimation and quota predictors.
Open a connector marketplace where agencies and customers can publish adapters for their bespoke tools (internal APIs, vertical SaaS). Provide an SDK for writing adapters that conform to the discovery schema. Let the community expand coverage to 100+ tools without engineering overhead.
Agents often need to coordinate (e.g., agent A enrich data in Salesforce, then agent B send email to those enriched records). Build a transaction and audit layer so multi-agent workflows are observable and can be replayed or rolled back if something fails.
This is not a founders-with-customer-traction idea. It is a platforms play that requires:
The ideal builder is a platform engineer who has shipped 2-3 agent deployments, hit integration pain, and wants to prevent that pain for the market. Someone from the Wes ecosystem (a former Sales Connector or TivAI engineer) is the natural candidate.
Why build it: If Wes ships this as open-source or a commercial platform (even closed to his companies at first), every agent platform becomes a customer. A $50/mo per-agent tier on 10,000 agents globally is $6M ARR. A $2-5K per-workspace annual tier for enterprises is $10-50M. This is not a feature; it is a category.
Months 0-2: Design the API schema (agent intent language, route response format, error handling). Recruit a co-founder with SaaS connector experience. Hire one backend engineer (connectors) and one data engineer (route learning).
Months 2-4: Ship connectors for 5 tools (Salesforce, HubSpot, Slack, Stripe, Twilio). Integrate into Vince Bot and Molly Bot. Iterate based on dogfood feedback. Hit 50% time spent on Zapier interop bugs and undocumented rate-limit tiers (this is normal).
Months 4-8: Expand to 10 tools. Publish API and docs. Onboard 2-3 external agent teams (not necessarily for revenue; for signal). Discover that observability is harder than expected - allocate 20% of team to logs and traces. Ship cost estimation (harder than it sounds due to volume discounting).
Months 8-12: Launch connector marketplace. 30-50 community connectors come in (expect 80% to be incomplete or undocumented). Ship v2 of the routing algorithm with basic ML. Land 1-2 enterprise pilot customers. Revenue: $0-50K depending on go-to-market approach (closed ecosystem vs. open platform changes the model drastically).
Reality checks: