Taking the time to point a coding agent towards the public (or even private) API of a B2B SaaS app to generate a working (partial) clone is effectively "unblocking" the agent. I wouldn't be surprised if a "DTU-hub" eventually gains traction for publishing and sharing these digital twins.

I would love to hear more about your learnings from building these digital twins. How do you handle API drift? Also, how do you handle statefulness within the twins? Do you test for divergence? For example, do you compare responses from the live third-party service against the Digital Twin to check for parity?

If the goal is to stop breaches, we should mandate MFA and ban default-public cloud buckets. Those are technical solutions. GDPR, instead, mandates a massive administrative layer. No data breach has ever been stopped by a well-drafted Privacy Impact Assessment or a 50-page DPA. Those are legal shields, not security measures.

> then don't automate them: just add it to your DPO's job description.

The DPO isn't an engineer. To let them fulfill a request, I still have to build the internal tooling to query, redact, and export data from distributed production databases. Also, "I'll have my DPO do it manually" never sounds good when going through an audit.

> they may simply be being kind.

The simpler explanation is that the average person has no clue what these rights are because they’ve never had a reason to care. In healthcare, patients care that their data is secure and the service works. They aren't losing sleep over "data portability."

Ultimately, this "level playing field" only benefits incumbents. Unethical players ignore the rules until they’re caught, while legitimate startups are hit with a compliance tax that makes it nearly impossible to compete with US-based firms that can focus 100% of their energy on the product.

We didn't spend thousands of hours on a deletion feature (or just development time). We spent them in total to be compliant in a healthcare environment. That time goes into:

Documenting the entire lifecycle (how, why, and where) of every single data point we process. Conducting and documenting formal risk assessments for every major processing activity (Privacy Impact Assessments (DPIA)). Drafting and negotiating data processing agreements (DPAs) with every single partner and vendor we use. Building strict role-based access and logging systems to track exactly who views and edits data and why. Implementing pseudonymization and logical data separation to ensure we meet "privacy by design" standards. Constantly coordinating between the product and dev team and the DPO to update policies and communicate changes to users.

The point I’m making is that the EU has built an incredibly expensive regulatory environment to support rights that, in practice, the vast majority of users don't seem to care about. We’re over-engineering for a "loss of control" that the average user hasn't shown much interest in reclaiming.

While the goals are usually noble, I’m increasingly convinced we’re regulating ourselves into irrelevance. I’m not a Big Tech company yet my interests align with theirs. We desperately need an EU that prioritizes actual growth over well-intentioned paperwork. To me, the AI Act and the GDPR are the worst offenders here, representing the largest possible gap between "good intentions" and the actual effect they have on the ground.

Consider frontier LLM labs. We have the talent, the Nordic data centers, and access to the GPUs. But why would any investor drop $100B on a frontier LLM lab here when the legislative environment is fundamentally more hostile than the US? It feels like we’ve already watched Mistral and Aleph Alpha get left in the dust.

To give you an idea of the "compliance vs. reality" GDPR gap: I worked on a project processing healthcare data for millions of people. We had a clear, easy-to-find privacy policy and a responsive DPO. Total GDPR requests for info or deletion? Exactly 53. Out of millions. We spent thousands of hours building systems for rights that only 0.001% of our users cared to use.

If you look at the courts, the "damage" being prevented is equally vague. Since EU courts don't really do punitive damages, most awards are tiny unless there’s actual identity theft. Most of what GDPR protects is "mental distress" or "loss of control"-concepts so ambiguous that courts rarely award anything for them unless something else went wrong.

The result of all this "protection"? No FAANG-equivalent, no frontier AI leader, and no homegrown ad-tech. It turns out the most perfectly regulated company is the one that never exists in the first place.

1. Sub-agents are just stack frames. When the main loop encounters a complex task, it "pushes" a new scope (a sub-agent with a fresh, empty context). That sub-agent runs its own REPL loop, returns only the clean result with out any context pollution and is then "popped".

2. Shared Data is the heap. Instead of stuffing "shared data" into the context window (which is expensive and confusing), I pass a shared state object by reference. Agents read/write to the heap via tools, but they only pass "pointers" in the conversation history. In the beginning this was just a Python dictionary and the "pointers" were keys.

My issue with the heavy SDKs isn't that they try to solve these problems, but that they often abstract away the state management. I’ve found that explicitly managing the "stack" (context) and "heap" (artifacts) makes the system much easier to debug.

Read: Gather context (user input + tool outputs). Eval: LLM inference (decides: do I need a tool, or am I done?). Print: Execute the tool (the side effect) or return the answer. Loop: Feed the result back into the context window.

Rolling a lightweight implementation around this concept has been significantly more robust for me than fighting with the abstractions in the heavy-weight SDKs.

So in this case, you probably want to opt for accidents of lower severity. Metal undents more easily than flesh.

[0] https://waymo.com/blog/2024/05/fleet-response/

Building a useful forward looking financial model mostly involves qualitative analysis. This means thoroughly examining the company's and competitors' 10-Ks and 10-Qs, digesting industry reports, understanding the company’s business model, breaking down the underlying mechanics of the income statement, balance sheet, and cash flow statement, identifying the core processes driving value creation, forming solid hypotheses on how the business will evolve, etc.

I believe Perplexity, as an advanced answering engine, provides a strong foundation for supporting this kind of in-depth research and hope to see the platform evolve into this direction.

I believe this statement is accurate. Your comment does not alter this fact and merely imposes an arbitrary requirement instead of giving credit where credit is due.

If another company were to openly share alternatives to Meta's core assets, I would welcome that as well.

In the end, this would solve the allocation problem while maximizing the available public housing. It would take a couple of years or decades to reach an equilibrium state I guess.

I'm probably missing something obvious here. Can somebody point out my mistake?