I'm also not confident this is something that will stick (and survive the acquisition), which further weakens the idea that companies would set up expensive migration projects to it.
Is the goal to build something and learn something from the experience, or try and build something with adoption in mind?
If the former, the answer to your question is always "yes": if there's something to learn and you're interested in that problem space, it's always worthwhile.
If you're looking at the latter, you're essentially building a product. The next question should then be "is there part of what's out there that you're confident you can do differently/better?"
Not too long ago, a recruiter reached out for a confidential client that turned out to be ClickUp with a posting that felt off (600-900k + stock and bonus compensation), I was left wondering what kind of insanity is rolled into the job for this amount. Now I know.
I'm a bit confused about the offering here, it feels like Amp is positioning itself as a reseller of sorts. Couldn't the startups just purchase compute directly from AMZ/GCP/Azure? Through direct or indirect ownership, I'd bet that the datacenters being dealt with would be under those anyway.
> Some start-ups may share digital data needed to train A.I. models.
Your data being used by the companies you're dealing with directly is one thing, but it being open for untold loose partners you have no connection too feels like it should be a bridge too far.
How does this compare to YAML and TOML? It feels that both of the above would be in the same bucket of "fewer tokens than JSON/XML and generally easier on the eye", with the benefit of having a pretty rich ecosystem already.
I'd be curious to hear about whether this has an edge when it comes to performance in any way, or whether it solves for a problem that other formats are missing the mark on.
I didn’t look at the account or provenance, but I’m more wondering about the actual content.
“I was in Europe” -> where? Why would the car be configured in English? I’ve rented cars in Spain, Germany, Denmark and France, and they were all in the country’s language.
“6 lane highway” -> again, where? Or is it meant 3 lanes per side? Because 6 lanes on each side are few and far between in Europe.
My car will get pissy when it’s in semi-self-driving and it can’t detect my hands on the steering wheel. It will start beeping and stuff for a very long time before slowing down and eventually stopping.
I’m also a bit surprised about the statement she couldn’t figure out what was wrong. Do people _not_ look at their dashboard when the car makes a noise to get their attention?
It’s also odd that she didn’t mention the actual car brand and model. This is 100% something that needs to be investigated and checked, and name and shame is the correct approach.
I doubt I see what this has to do with government tracking; it’s about making sure people don’t doze off. I don’t believe there’s any facial recognition involved.
> When an agent spends money or creates liability, who's responsible?
Whoever is operating it (as in, you or the entity providing you the service if you're using someone else's thing). If I operate a coffee machine accessible to others and it injures someone, I'm on the hook; the same logic applies to an agent. At the end of the day, LLMs are tools, and whoever is overseeing it is vouching for it (and paying the price if it misbehaves).
> Personal accounts are risky and manual LLCs don't really scale?
When it comes to personal accounts, I assume you're talking about use cases like "I use an agent in my personal capacity to do things and it made a mistake". This sounds like you're shouldering the risk and accept the potential consequences. That's just a case of "I did something risky, and found out".
As for the manual LLC bit, I'm assuming you are thinking about an agent as part of a business. In that case, whoever is operating the business is on the hook.
The idea that agents should be legal entities just sounds like an attempt at shifting blame away for doing risky things knowingly.
reply