The "AI" "agent" "helpdesk" they pivoted into is such a grift. AI agents still does not solve the main issues that makes a person contact support in the first place. How do I know? I was a founder in the space.
but good for them that they got salesforce to buy it.
Since we're sharing anecdotes, I work in this space and my team automated a large part of customer support for a large scale up using an AI agent. The kicker is that customers rate their interactions with the AI agent higher than their interactions with customer support staff.
AI is definitely capable of taking on customer support work at the moment, and to a high standard as well. Sure, it's not perfect. But it's not a grift either.
Solving 80% of menial support tickets automatically through agents trained on your help center, freeing up your actual support agents to focus better on meaningful tasks seems a tiny bit more than a grift.
I’m not sure where you’re getting this from but their customers find Fin to be a hugely impactful tool
The reason people want to get a human on the other end of the line is usually because they want some sort of remediation,like a refund or need to escalate something to someone who can take an action. Right now, AI agents just barf the FAQ back at you. Which is great for your tier 0 calls, but without an easy way to bypass they are just underlining the problem inherent in gethuman.com needing to exist.
Now if AI agents are free to issue refunds or discounts by their own? Great, let's do that and suddenly most people are on board. But get ready for rampant abuse.
Best solution would be an AI cyborg system where it readies a recommendation and a human swings by and approves or denies it without wasting time talking to people. But users would hate that (anti-social), it would still be ripe for abuse. But it is likely the longer term solution, as people will quickly realize they can use web chat or Google AI to get the exact responses as your FAQ bot which means you have removed actual customer service and this is a non-product.
The newest AI Agents are much more advanced that "FAQ bots", they kind of have hybrid deterministic and non-deterministic flows in how they handle customer requests, depending on the request.
Some companies set them up exactly as you describe, they handle the low effort, easy to solve issues and then escalate to a human for "bigger" things. There is still a lot of value in that process as now maybe 76% of your customer requests are solved without human intervention and the humans agents can focus on the more meatier requests.
Some companies do not though, I know of Airlines using AI Agents with full flight re-booking flows happening end to end with no human intervention and its working well.
I think AI Customer Service Agents have already moved beyond what you yourself have personally witnessed.
If I had to guess, there's two things they feel AI doesn't address:
1. People wouldn't need to contact support if you just made quality goods and services. Outside of rare exceptions and inquiries, of course.
2. AI has not advanced enough to trust it outright, nor does it have a physical body. So it can't really do anything you wouldn't already just be able to put in the UI for the customer, without needing it's actions reviewed and confirmed by an accountable human. See: accidental truck giveaways.
So investing into AI support over making your business better is seen as misallocation. And using AI support instead of just improving the service is seen as inconvenient. And using AI support when it needs humans to do the support anyway is seen as inefficient.
> People wouldn't need to contact support if you just made quality goods and services
It'd be weird to start a startup around that, sounds like something for a consulting business instead, parent specifically mentioned they've founded customer support startup, must be something actually related to customer service, I'm assuming.
We’ve been working on a browser-based Link Graph (osint) analysis tool for months now (https://webvetted.com/workbench). The graph charting tools on the market are pretty basic for the kind of charting we are looking to do (think 1000s of connected/disconnected nodes/edges. Being able to handle 1M points is a dream.
That's a cool project! Just checked out the workbench. I should be upfront though: ChartGPU is currently focused on traditional 2D charts (line, bar, scatter, candlestick, etc.), not graph/network visualization with nodes and edges. That said, the WebGPU rendering patterns would translate well to force-directed graphs. The scatter renderer already handles thousands of instanced points - extending that to edges wouldn't be a huge leap architecturally.
Is graph visualization something you'd want as part of ChartGPU, or would a separate "GraphGPU" type library make more sense? Curious how you're thinking about it.
Really fantastic work! Can't wait to play around with your library. I did a lot of work on this at a past job long ago and the state of JS tooling was so inadequate at the time we ended up building an in-house Scala visualization library to pre-render charts...
More directly relevant, I haven't looked at the D3 internals for a decade, but I wonder if it might be tractable to use your library as a GPU rendering engine. I guess the big question for the future of your project is whether you want to focus on the performance side of certain primitives or expand the library to encompass all the various types of charts/customization that users might want. Probably that would just be a different project entirely/a nightmare, but if feasible even for a subset of D3 you would get infinitely customizable charts "for free." https://github.com/d3/d3-shape might be a place to look.
In my past life, the most tedious aspect of building such a tool was how different graph standards and expectations are across different communities (data science, finance, economics, natural sciences, etc). Don't get me started about finance's love for double y-axis charts... You're probably familiar with it, but https://www.amazon.com/Grammar-Graphics-Statistics-Computing... is fantastic if you continue on your own path chart-wise and you're looking for inspiration.
Thanks - and great question about direction. My current thinking: Focus on performance-first primitives for the core library. The goal is "make fast charts easy" not "make every chart possible." There are already great libraries for infinite customization (D3, Observable Plot) - but they struggle at scale.
That said, the ECharts-style declarative API is intentionally designed to be "batteries included" for common cases. So it's a balance: the primitives are fast, but you get sensible defaults for the 80% use case without configuring everything. Double y-axis is a great example - that's on the roadmap because it's so common in finance and IoT dashboards. Same with annotations, reference lines, etc. Haven't read the Grammar of Graphics book but it's been on my list - I'll bump it up. And d3-shape is a great reference for the path generation patterns. Thanks for the pointers!
Question: What chart types or customization would be most valuable for your use cases?
Most of my use cases these days are for hobby projects, which I would bucket into the "data science"/"data journalism" category. I think this is the easiest audience to develop for, since people usually don't have any strict disciplinary norms apart from clean and sensible design. I mention double y-axes because in my own past library I stupidly assumed no sensible person would want such a chart -- only to have to rearchitect my rendering engine once I learned it was one of the most popular charts in finance.
That is, you're definitely developing the tool in a direction that I and I think most Hacker News readers will appreciate and it sounds like you're already thinking about some of the most common "extravagances" (annotations, reference lines, double y-axis etc). As OP mentioned, I think there's a big need for more performant client-side graph visualization libraries, but that's really a different project. Last I looked, you're still essentially stuck with graphviz prerendering for large enough graphs...
Ha - the double y-axis story is exactly why I want to get it right. Better to build it in properly than bolt it on later.
"Data science/data journalism" is a great way to frame the target audience. Clean defaults, sensible design, fast enough that the tool disappears and you just see the data.
And yeah, graphviz keeps coming up in this thread - clearly a gap in the ecosystem. Might be a future project, but want to nail the 2D charting story first and foremost.
Thanks for the thoughtful feedback - this is exactly the kind of input that shapes the roadmap.
You may enjoy Graphistry (eg, pygraphistry, GraphistryJS), where our users regularly do 1M+ graph elements interactively, such as for event & entity data. Webgl frontend, GPU server backend for layouts too intense for frontend. We have been working on stability over the last year with large-scale rollout users (esp cyber, IT, social, finance, and supply chain), and now working on the next 10X+ of visual scaling. Python version: https://github.com/graphistry/pygraphistry . It includes many of the various tricks mentioned here, like GPU hitmapping, and we helped build various popular libs like apache arrow for making this work end-to-end :)
Most recently adding to the family is our open source GFQL graph language & engine layer (cypher on GPUs, including various dataframe & binary format support for fast & easy large data loading), and under the louie.ai umbrella, piloting genAI extensions
my 2 cents: I'm one of these people that could possibly use your tool. However, the website doesnt give me much info. I'd urge you to add some more pages that showcase the product and what it can do with more detail. Would help capture more people imo.
We’ve been experiencing the same thing. On further inspection, we discovered that the owner of the data centers was Tencent. So we blocked them at the ASN level across countries.
This was after web had to geo block China & Singapore some weeks earlier.
These AI scraping guys are destroying the web for normal folks in these countries where they run data scrapers.
Did they really have to geo-block entire countries? I think the blocks of unrelated users is what's really affecting normal folks and that's the choice of operators.
It's like if you had incidents with a few violent drunk Brovanians in your town, then saying it's those few peoples fault that Brovanians are now being discriminated against and are being banned from entering shops just because they come from the same place as the vandals.
Site operators arbitrarily blocking entire countries due to a few botters (albeit with a lot of bots) causing issues aren't without responsibility in the loss of an open web.
You have a choice in how to respond and where to draw lines. We can't just throw up our hands and blame the botters.
the service is a suite of online vetting and due diligence tools for website flippers, Fb marketplace sellers/buyers and Tiktok shoppers
The domain has an interesting backstory. I acquired if it n 2022 from Epik after they stole the $10,000 I had deposited into their Escrow service. The money was meant for acquiring a newish stable diffusion hosting website that was competing with civit.ai. When the Epik issue was discovered, the seller pulled out.
Acquiring that website could have changed my life.
One thing this really points out to me is how no one really believes in anything. Bernie Sanders position today is markedly different from this 2011 position only because of current party affiliation
As someone who has primarily used Laravel for almost 10years, this makes me sad. Laravel being venture backed will put all sorts of pressure on the company and force the project to be modified in so many ways to justify the capital raised. From my knowledge, the company was churning along quite well. I wonder what the money raised will be used for.
but good for them that they got salesforce to buy it.