Gemini generateContent request failed: { "error": { "code": 429, "message": "You exceeded your current quota, please check your plan and billing details. For more information on this error, head to: https://ai.google.dev/gemini-api/docs/rate-limits. To monitor your current usage, head to: https://ai.dev/rate-limit. ", "status": "RESOURCE_EXHAUSTED", "details": [ { "@type": "type.googleapis.com/google.rpc.Help", "links": [ { "description": "Learn more about Gemini API quotas", "url": "https://ai.google.dev/gemini-api/docs/rate-limits" } ] } ] } }

Before Claude Code, a full cloud migration could easily be a couple months. We migrated our whole stack to GCP in about a week. It's trivial to switch clouds now with K8 stack and Claude Code.

I couldn't find something, so I rolled a version together based on redis and job queues. It works decently well, but I'd prefer to use something better if it exists.

Does anyone know of something like this that isn't completely over engineered / abstracted?

I've been using BullMQ for awhile with distributed workers across K8 and have hacked together what I need, but a lightweight DAG of some sort on Postgres would be great.

I took a brief look at your docs. What would you say is the main difference of yours vs some of the other options? Just the simplicity of it being a single sql file and a sdk wrapper? Sorry if the docs answer this already - trying to take a quick look between work.

Here's the live mermaid editor version for the Ikea example: https://mermaid.live/edit#pako:eNqNkV9PwjAUxb9KcxPfRrO17E_3Y...

On the research, you're absolutely right. It fits that sweet spot where it's just easy / boring / tedious enough to automate with the current generation of LLMs.

We found that going both up the chain and down / sideways in the chain was too much for the agent to handle - they are two distinct operations. The #1 use case was customers trying to understand the ultimate parent, so we decided to focus on that first.

We have something roughly working on subsidiaries, but it's not ready for prime time yet. It would likely be a separate API.

We actually haven't explored the big consulting firms yet. I know they are often contracted to do this sort of research for companies.

Regarding the product, I'm open to any and all feedback for your use case. Trying to follow the adage of "if you are not embarrassed by the first version of your product, you’ve launched too late".

And wow - just read your reddit post. I'm going to look into that for us too.

We realized the underlying business graph was the bottleneck though, so that's been our focus for some time. With that in place, we're now coming full circle on the risk research standpoint.

On your comment about confidence / liability, we're actually having conversations around that now and getting feedback. First step is exposing all the research and evidence directly to build trust, which is what we're doing now for the new corporate hierarchy system.

## Summary IKEA US RETAIL LLC is a limited liability company. It is wholly owned by IKEA Holding U.S., Inc., and ultimately controlled by Stichting INGKA Foundation, a Dutch foundation that owns Ingka Group.

## Graph

  graph TD
    e2[IKEA Property, Inc.]-->e1[IKEA US RETAIL LLC]
    e3[IKEA Holding U.S., Inc.]-->e1[IKEA US RETAIL LLC]
    e4[Ingka Holding B.V.]-->e3[IKEA Holding U.S., Inc.]
    e4[Ingka Holding B.V.]-->e4[Ingka Holding B.V.]
    e5[Stichting INGKA Foundation]-->|100%, 1982|e4[Ingka Holding B.V.]

Had a show HN last week that seemed to go under the radar: https://news.ycombinator.com/item?id=45671087

We launched corporate hierarchy research and working on UBO now. From the corporate hierarchy standpoint, it looks like the Delaware entity fully owns the Estonian entity. Auto generated mermaid diagram from the deep research:

  graph TD
    e1[BuildJet, Inc.]-->|100%, 2022-12-16|e2[Buildjet OÜ]

  graph TD
    e2[SAIC MOTOR UK HOLDING CO., LTD.]-->|2005-02-15|e1[MG MOTOR UK LTD]
    e1[MG MOTOR UK LTD]-->|2018|e7[MG Sales Centre Limited]
    e4[SAIC Motor Corporation Limited]-->e2[SAIC MOTOR UK HOLDING CO., LTD.]
    e4[SAIC Motor Corporation Limited]-->e3[SAIC MOTOR INTERNATIONAL UK LTD]
    e5[Shanghai Automotive Industry Corporation Group]-->|62.69%|e4[SAIC Motor Corporation Limited]
    e6[Shanghai State-owned Assets Supervision and Administration Commission Shanghai SASAC]-->e5[Shanghai Automotive Industry Corporation Group]

Happy to run lookups for other companies if anyone's curious what their ownership looks like!

The problem: Companies spend millions on manual research teams to answer compliance / risk questions like, "does this business roll up to a state owned entity in China / Russia?". A bankruptcy processor we work with had 30 people just manually researching data points like this. An ex-Shell trader told us Shell has 800 people + $100M/yr spent with Deloitte to conduct manual research to ensure international trade compliance.

Why existing solutions are lacking: The dirty secret is that legacy providers like Dun & Bradstreet, Orbis, and S&P run on armies of manual workers and are built on decades old technology. At query time, you’re typically tapping into a quarterly generated, static, expensive database.

Our approach: We built this on top of our entity resolution engine - a deep research agent that anchors entities to our business graph, powered by direct integrations with government registrars and our web scraping infra. When you need hierarchy research, our AI agents spend on average 10-20 mins researching upward to identify the ultimate parent and build the complete ownership DAG with source citations. We auto-generate Mermaid diagrams so you can immediately render the results in your own app.

Technical backstory: I've spent 10 years building MDM, data enrichment, and entity resolution systems at B2B startups and enterprises, mostly in fintech. I actually built an in-house Clearbit replacement after they overcharged us and almost killed the startup I was at. The core challenge is always the same - taking messy business data and mapping it to web data and the actual legal entity. Most off the shelf solutions are mediocre because they skip the hard part: the gnarly 20-40% of records that force you into manual research.

Current state: Just three of us, bootstrap funded. We're getting requests for full subsidiary mapping too, but focused on upward hierarchy for now. We're still figuring out pricing (market rate seems to be a few dollars a lookup, but we aim to be a fraction of that). Deep research is expensive but we think we can make it work at scale.

Try it:

- Interactive demo: https://savvyiq.ai/products/entity-hierarchy (no signup)

- Free account: https://savvyiq.ai/signup

- API docs: https://savvyiq.ai/api-reference#tag/entity-hierarchy-beta

Would love feedback on the hierarchy API specifically, including the schema, gaps / edge cases, but also curious about other use cases where business identity resolution is a pain point for you.

Happy to run a few entity hierarchy lookups in the comments if anyone wants to see the API in action - I can share the results as Mermaid diagrams that you can paste directly into any Mermaid renderer.

Comments URL: https://news.ycombinator.com/item?id=45671087

Points: 17

# Comments: 10

For anyone interested:

CREATE FUNCTION uuidv7() RETURNS uuid AS $$ -- Get base random UUID and overlay timestamp select encode( set_bit( set_bit( overlay(uuid_send(gen_random_uuid()) placing substring(int8send((extract(epoch from clock_timestamp())*1000)::bigint) from 3) from 1 for 6), 52, 1), -- Set version bits to 0111 53, 1), 'hex')::uuid; $$ LANGUAGE sql volatile;