In the partnership model Waymo charges uber for the ride and Uber charges the customer.
The interesting thing is that uber loses money on every ride. Waymo charges Uber more than Uber charges the customer.
On Uber’s side, though, this is preferable to losing the entire ride. Uber loses much more slowly by controlling the distribution and losing a few dollars per ride than by losing the entire customer base with no revenue from these customers.
AFAIK, it's due to things like single frame construction and expensive + backlogged parts which you order directly from Tesla (as opposed to, eg, a drivetrain that may be made for 3 separate manufacturers).
Or, when you do have an accident it's typically more expensive to repair.
There are only a few popular, promoted alternatives to NextJS right now (that I know of): Remix and TanStack. That is, if you're fully React focused, ofc. I dont see promoting Remix as a red flag.
Promoting it? No problem. But promoting something you profited from without disclosing it violates FCC rules for broadcasting. I would say influencers aren't technically broadcasting but they are in principle.
The framework itself is super low overhead. You can deploy this anywhere, and if you deploy to inngest.com the P99 latency of starting agents is sub-50ms (and you can also realtime stream steps, tools, or model responses to the browser).
One of the main differences is the DX — _how_ you define the agentic worklflows is far cleaner, so it's both faster to build and fast in production.
Each agent builds up state via tool use. On each loop of the network, you inspect this state to figure out which agent to run next. You don't build DAGs or create odd graphs — you write regular code in a router.
Or, more generally:
* Each agent has a specific goal within a larger network. Several agents each working on smaller goals means easier prompt generation, testing, iteration, and a higher success rate.
* The network combines agents to achieve an overall objective, with shared state modified by each agent
* The network’s router inspects state and determines which agent should run next
* The network runs in a loop, calling the router on each iteration until all goals are met
* Agents run with updated conversation history and state on each loop iteration
Realistically the challenge with agents has classically been: how can I build something reliable, and how can this run in production reliably? These patterns are largely what we've seen work.
Thanks for explaining. But I guess I'm still not clear on how the work gets divvied up. Not tryin to be a hater - I'll have to give it a spin - but that part's a bit murky to me still.
It took less than a day to get a network of agents to correctly fix swebench-lite examples. It's super early, but very fun. One of the cool things is that this uses Inngest under the hood, so you get all of the classic durable execution/step function/tracing/o11y for free, but it's just regular code that you write.
The interesting thing is that uber loses money on every ride. Waymo charges Uber more than Uber charges the customer.
On Uber’s side, though, this is preferable to losing the entire ride. Uber loses much more slowly by controlling the distribution and losing a few dollars per ride than by losing the entire customer base with no revenue from these customers.