Your AI Co-Worker in Slack & iMessage
Bringing an AI coworker directly into Slack and iMessage is a logical way to cut down on app-switching fatigue. Instead of jumping between dedicated browser tabs for Claude, ChatGPT, and design tools, your team can trigger multi-modal tasks where the actual communication already happens. The "right model for the right job" approach (routing design, coding, or text to specific specialized backends) is a smart architectural choice that prevents overpaying for overkill models. Operating a heavy agent fully on "Autopilot" through a messaging interface requires strict guardrails. It needs highly transparent execution logs inside the chat thread so team members can audit what actions the agent is planning to take before it executes them on external platforms. Additionally, while iMessage support is a solid feature for solopreneurs, handling deeply nested team context and role permissions over a standard SMS/iMessage protocol is naturally limited compared to Slack's structured channel environments. More robust access-control management is highly needed. I’ve evaluated basic custom Slack bots hooked up to standard OpenAI APIs, as well as standalone multi-agent orchestration frameworks. While custom API scripts offer deep flexibility, they require constant maintenance and don't feature native context sharing out of the box. I opted to look into Scarlett because it packages the multi-model architecture, background autopilot capabilities, and third-party media keys into a unified workspace without requiring us to manage separate infrastructure configurations.
Hello PH fam! Long before there was Claude Tag and Victor, there was Scarlett. We built Scarlett over a year ago as a fun experiment to see what agents could do. To our surprise, she almost immediately started doing probably 90% of our work for us. We've been reluctant to launch because we knew the competition would be fierce, but our benchmarks show that Scarlett is more than holding her own on both speed & quality. She also has a host of unique qualities & features: 1) She Just Works. After a year of experimenting with various models, architectures & backends, she just works (and does work). 2) Autopilot. She is trained on 50+ business/growth books, you have the option to use her passively or to set her free to essentially run your whole company from marketing to support. 3) iMessage. A lot of people (solopreneurs) don't like or need slack, so we have an alternative. 4) Use Our Keys. With OpenClaw, Claude, etc you need to buy subscriptions to the things you want to use like HeyGen or XAI, but with Scarlett you can use our keys and we'll pass along the cost. 5) Right Model, Right Job. You can use Opus for chat, Sol for Coding, Fable for design, you pick the right model for the job. We hope you love her as much as we do! Cheers, Dan Show more
Love how the landing page cuts straight to the point with "real colleague" framing instead of leaning on the usual AI buzzwords. The copy feels like it was written by someone who actually understands team workflows, not just tossed into a prompt.
Passing API costs through a single source removes a lot of friction for developers, it keeps the focus on building instead of managing keys and billing. Great work Dan Sutera this looks like a fantastic tool. any plans for native vector database integrations for long-term semantic memory? congrats👏👏
@vikramp7470 Yeah, I've used OpenClaw personally for a while and the API / subscription management has been a giant pain in the ass, so TBH i think this is one of her best features. Regarding memory, we've done a lot of work on it and tried various things. We are currently running a version similar to Viktor with a Karpathy style wiki, but we keep in SQL like Hermes does for better speed. We also tried running Obsidian & Vector dbs in parallel but they seemed to confuse things in context as much as they helped. I think this overall is a moving target and we're always looking for improved products or architectures here. Thanks Vikram!
@dansutera Makes total sense, sticking to SQL like Hermes for speed is a solid architectural choice, Good luck with the launch today...
@asya2rke Thanks Asya! Have to credit our designer @cynthiacui with the beautiful (and straightforward) landing. Yeah we are trying to reach a non-technical audience here and put all the complicated stuff behind the curtain. Like we don't want users to have to worry about API's or anything, just connect a few things, ask Scarlett for stuff and it's done.
Congrats on the launch, Dan! 🚀 It’s awesome to see you guys pulling back the curtain on how Scarlett runs. The decision to skip the traditional Vector DB route and stick to an SQL-heavy setup for speed (similar to Hermes) is a really fascinating engineering choice. Since you mentioned Vector DBs sometimes over-cluttered the context, how do you handle deep semantic search or long-term recall when a user asks about a conversation from months ago? Is it purely structured querying, or do you have a hybrid text-search layer built into the SQL database?
@franz_briones Thanks Franz! I asked Scarlett to explain it herself... here's what she said: "Good question, this was one of the trickier calls. Short answer: it's a hybrid. We didn't drop semantic search, we just folded it into the SQL layer instead of running a separate vector DB. Postgres full-text search handles most "find where we talked about X" recall. For fuzzier matches, we keep vector similarity as a column/index right next to the structured rows, so one query can filter on structure (who, when, which entity) and then rank by semantic closeness. That structured pre-filter is what kills the over-clustering problem: we prune the candidate set before semantic ranking, so we don't drag in the loosely-related noise a pure top-k vector lookup would. For long-term recall we don't re-scan everything, raw messages get compiled into entity-scoped, source-backed memory, so old questions resolve against compiled facts first and drill into raw evidence only when someone needs the exact quote. So: structured querying as the backbone, with lexical and vector layers riding inside the same engine. Speed and clean context were the whole point." So we have a Karpathy style wiki for long term, but it's stored in the db just structurally.
Love the "right model, right job" approach ☺️☺️ Curious how you think about external tools and live data, do you see Scarlett becoming more of an orchestrator that can plug into specialized capabilities over time, or do you prefer building everything natively?
Congratulations on the launch! Scarlett sounds like a practical AI agent rather than just another chatbot. how does she decide when to act autonomously versus asking the user for approval, especially in business workflows?
the Autopilot capability sounds powerful. for founders who are just getting started, what are the first three workflows you would recommend automating with Scarlett to see value quickly?
Hey Agus, thanks for the review. Glad you dig it!!
@luki_notlowkey hey Luki, thanks! Trying to keep Scarlett out of the way as possible, so much more orchestrator vs. native. There are so many great tools and API's and models coming, we want her to basically connect the dots between them & your company and keep the UI via slack or imessage dead simple. So whenever a cool new tool comes across the Twitter/X feed, she can ingest/connect to it as a capability then figure out how that fits into the mix for your company.
@imogen_wallace Thanks Imogen! Autopilot is great yeah. Workflow-wise i like to get daily company report going. Daily customer triage. And automating whatever your main social is such as X.
@avery_thompson2 thanks Avery! The autopilot is autonomous, but you can turn on or off and change frequency. Autopilot will ask for help / approval if it thinks its necessary. Normal scarlett mode (autopilot off) is always acting only when asked.