Delphi / Anon — Engagement Notes

Delphi / Anon — Engagement Notes

Notes for meeting on 8/22:

Context

  • Want to provide an update, get the latest on Delphi, and align roadmaps!

Anon Product Demo

  • The following demo shows the Anon product end-to-end working with our client-side SDK on iOS and the server-side SDK.
  • This shows the flow for:
    1. A developer requesting LinkedIn access
    2. A user receiving and responding to a push notification from Anon (could be Delphi)
    3. A user authenticating LinkedIn access using Anon (again, can be in any app).
    4. The user session being passed to a separate browser runtime for automation.

Dev Doc Access:

Integration Validation

🗒️
All integrations are generally supported, but validation is us testing integrations on various devices (mobile, desktop, etc.) with various client-side SDKs (iOS, Chrome extension, etc.) and at least one browser runtime (Playwright, etc.) to make sure we can consistently support the integration.
  • Completed and tested:
    • ✅ LinkedIn (including messenger)
    • ✅ Github
    • ✅ Uber
  • Priority queue — relevant for Delphi
    • ☑️ Instagram (including messenger)
    • ☑️ Facebook (including messenger)
    • ☑️ Twitter (including messenger)
  • Priority queue — less relevant for Delphi, but for context.
    • ☑️ Amazon
    • ☑️ United Airlines
    • ☑️ Expedia
    • ☑️ Lyft
    • ☑️ Marriott
    • ☑️ Reddit
    • ☑️ OpenTable
    • ☑️ Spotify
    • ☑️ Zillow

Anon high-level roadmap and timing:

  • This week:
    • Developer docs finished.
    • Both client-side and server-side SDKs published.
  • Next week:
    • Formal validation of key integrations from ☝️ section.
  • By early-mid September:
    • Swagger/OpenAPI spec published for REST API.
    • Ready to begin onboarding design partners for testing.
  • By mid-late September:
    • Support for production launch (in beta) with initial partners.

Notes from prior email thread:

Specifically, Daniel send the following via email to show how the autoresponders would work as it relates to creator user experience:

Use Case 1: Mr. Beast Uses Delphi Instagram Autoresponder

  • Mr. Beast signs up with Delphi (congrats!)
  • As part of signup, Mr. Beast (or more  with the login to his Instagram) would .
  • likely someone from his team

    install the Anon Chrome extension

  • That person would then login to Instagram  to connect the auto-responder functionality.
  • with the extension installed

  • The service would , at least until a re-authentication is needed (could be weeks, could be 6 months — depends on the service).
  • then work fine

  • When a re-auth is needed, that same person (or ) would need to .
  • anyone with both the Anon extension + access to the Instagram

    login again to refresh

    credentials

Use Case 2: Mr. Beast Trains Model on TikTok + IG Data for Clone Creation

  • Basically the same thing.
  • The key thing is that a single person on his team with  just has to authorize primary access, and then be prepared to re-authenticate at various points in the future.
  • both access to his Instagram and the Anon Chrome extension

I hope that helps!  The complexity is all on the creator side (or the creator's team).  This enables Delphi users to interact with Delphi via Instagram directly with no extension.

And Daniel clarified that:

  • Connection needs to happen up-front and then only again when the session requires a refresh.
  • Onboarding should be relatively seamless and <5 minutes of setup time to authenticate the creator’s account to use the auto-responder. Subsequent refreshes should be extremely short (<1 minute) and are dependent on the session tokens for each service.

Notes for meeting on 7/18:

Context and Overview

  • Dara (Delphi) and Daniel (Anon) were introduced by Jordi.
  • Delphi is building a digital clone platform for experts.
  • Anon is building infrastructure for user-permissioned data integrations.
  • Based on a quick conversation, Anon could help Delphi in two ways:
    • Short-term: Add messaging integrations for clones (IG, FB, Twitter, LinkedIn).
    • Long-term: Add new permissioned data integrations for training clones.
  • For now, we’ll focus only on the short-term opportunity.

Product Planning Scope

Product overview

  • Delphi will launch its creator product in mid-August. Creators can sign up, create a clone, import data to train it, and deploy it to interact with their audience.
  • Messaging integration allows creators to put in-app messaging on "autopilot" with Delphi's AI as the first responder to DMs, while still allowing the creator to interject at any time during the conversation.
  • Anon provides this messaging app integration, allowing creators to authenticate accounts and maintain persistent sessions for Delphi's AI to send and receive DMs.

Disclosure of risks

  • Social media platforms such as IG and FB explicitly ban "bot traffic". At present, this includes AI agents like Delphi. To win here, we build tech to handle MFA or Turing test-style challenges and manage network-level routing to proxy web sessions. This is precisely what Anon's tech is designed to do, and we are good at it.
  • But, at this stage, nobody is perfect. We are 10x more effective than anyone else (or doing it yourself), but accounts can still get “flagged”. Usually, this is no big deal. Creators will need to re-authenticate or go through a short account recovery flow. Accounts can also get “blocked” or banned. This is extremely rare, and it’s almost always possible to reverse, but it is a possibility.

Phased rollout strategy

  • To nail the product UX and minimize risks, we propose a phased rollout of this product between Anon and Delphi. We start with a finite set of services, and creators, and roll the product out in waves. Thoughts on this plan below:

First, create a shortlist of services:

  • On the call, we discussed IG, Facebook, and Twitter.
  • We can technically support any app-level messaging service — including LinkedIn, Slack, Discord, etc., and likely (in the future) services built on other protocols like iMessage, WhatsApp, Telegram, etc. Basically, any service with a website we can support easily. Any service with an app only (dating apps, etc.), is do-able, and any service that requires authenticating with a phone number is more challenging, but do-able, as well.
  • We would recommend ordering services and rolling out one-by-one:
    • (1) Instagram
    • (2) Facebook
    • (3) Twitter
    • …etc

Second, limit the rollout to a select set of creators:

  • Ideally, we would target a set of “friendly” creators for the initial rollout. Delphi could offer to let them test a premium “alpha” version of the messaging product, and we could closely partner with them to provide a white glove service.
  • Ideally, we start with a small cohort (10 creators?) and then expand to 50, 100, 500, etc. based on pre-agreed upon SLAs for uptime, latency, customer feedback, etc.

In summary, we could do something like this:

IG Messenger
FB Messenger
Twitter DMs
..service #4
Alpha
Mid-Aug.
Oct.
Nov.
Jan 2024
>10 creators
Sept.
Nov.
Dec.
>50 creators
Oct.
Dec.
Jan 2024
>100 creators
Nov.
Jan 2024
>500 creators
Dec.
>1000 creators
Jan. 2024

Next Steps

  • Firstly, we’re stoked to find a way to work together and think this could be a very valuable partnership for both companies.
  • Let’s meet and make sure we’re aligned on the product scope and that the rollout strategy and timeframes could work for Delphi, then we can dive into the technical and commercial details and get started 🤝.