Thanks! Yea it started as a bit of an anger management project. I am the absolute worst version of myself when forced to endure customer service calls.
1. The user (you) needs to provide it in the prompt for the call. I have ideas for being able to build memory context for each user so you wouldnt have to re-provide those details each time you want to make a call and instead pull it from memory bank, but thats not implemented yet.
2. So far I have actually never been called out for not being a human. I think thats in part because these people probably get a lot of pretty crazy calls and by comparison a slightly robotic over-the-phone voice has a lot of forgiveness. When you know, its easy to hear though. I did build it with Elevenlabs TTS to make the voice as natural as possible. Models have gotten much faster and so latency feels good, not outstanding
3. So this IS very interesting, I have to refine the system prompt extensively to get it to the right balance of objection handling without being weird and obviously non-human. It is very clearly on the side of the human, in fact in the NYT case it was initially told no but pressed ahead anyway. "I understand that, how do we move forward" "any other way we can resolve this" that kind of thing. Better still, customer service has a very high abr for hanging up the phone,so the persistency is very effective
Yes I think the API holds real potential. The space is busy, but I think there could be room for being the simplest possibel way to make a phone call programmatically. There would be less customization than a Vapi or Bland, but it would take 10 minutes to implement. Basically anywhere engineers experience automated workflows breaking because the real world requires a phone call. Voice probably wouldn't be core to these users business though, int hat case they'd want more control than we would offer.
Let me know if you have any issues trying it! Very curious to see how folks end up breaking it. We have a discord you can join here (https://discord.gg/2tn2ugXu) if you have any problems to troubleshoot (or email me!)
Yep, absolutely right! Combining our product with something like the carbon curing tech of Solidia or CarbonCure would make a net-negative concrete. I don't consider us competitors at all!
Impressive analysis! Missed out on a couple details, but I'll take that as a thoroughly researched/analyzed endorsement. Most importantly, we'll be scaling up a lot faster. Our current 1t/yr is just a demo. Our current roadmap is scaling up to a 300t/yr pilot in the next few months before setting up building a commercial plant (10kt+) in the second half of next year. Any chance we can poach you from Google? ;)
What's the status on your current 1t/yr demo? (i.e. is it fully operational?) What did you learn from it and what are the technical challenges to scale it up to bigger plants?
Absolutely! This is a big part of our thinking for how this integrates with future energy systems based on renewables. We'd offtake cheap electricity when oversupplied, like in California right now
1. The user (you) needs to provide it in the prompt for the call. I have ideas for being able to build memory context for each user so you wouldnt have to re-provide those details each time you want to make a call and instead pull it from memory bank, but thats not implemented yet.
2. So far I have actually never been called out for not being a human. I think thats in part because these people probably get a lot of pretty crazy calls and by comparison a slightly robotic over-the-phone voice has a lot of forgiveness. When you know, its easy to hear though. I did build it with Elevenlabs TTS to make the voice as natural as possible. Models have gotten much faster and so latency feels good, not outstanding
3. So this IS very interesting, I have to refine the system prompt extensively to get it to the right balance of objection handling without being weird and obviously non-human. It is very clearly on the side of the human, in fact in the NYT case it was initially told no but pressed ahead anyway. "I understand that, how do we move forward" "any other way we can resolve this" that kind of thing. Better still, customer service has a very high abr for hanging up the phone,so the persistency is very effective
Yes I think the API holds real potential. The space is busy, but I think there could be room for being the simplest possibel way to make a phone call programmatically. There would be less customization than a Vapi or Bland, but it would take 10 minutes to implement. Basically anywhere engineers experience automated workflows breaking because the real world requires a phone call. Voice probably wouldn't be core to these users business though, int hat case they'd want more control than we would offer.
Let me know if you have any issues trying it! Very curious to see how folks end up breaking it. We have a discord you can join here (https://discord.gg/2tn2ugXu) if you have any problems to troubleshoot (or email me!)