eclipsetheworld

I have been working on this issue for a bit, and the most interesting approach I have seen so far comes from the research domain of information-flow control, specifically Microsoft’s FIDES work.

The idea is not to distinguish instructions from data. It is closer to having different privilege levels. Not all code has to run in kernel space, some code runs in unprivileged user space. So what is the equivalent for LLM agents?

In FIDES-style systems, every piece of information that enters the agent context is labeled along two dimensions: integrity and confidentiality. Integrity captures whether the data is trusted or untrusted (i.e. could it contain a prompt injection attack). Confidentiality captures who is allowed to see or receive it [0].

The privileged agent, sometimes called the planning agent, should not directly see untrusted data because it would be susceptible to prompt injection attacks. In the article’s example, a bank transaction’s sender-supplied reference would be untrusted. Instead, the planning agent receives a variable token. It can then either delegate processing of that variable to an unprivileged / quarantined agent with no or limited tool access, or pass the token as a reference to a tool.

Tools then have policies attached to their arguments and outputs. These policies specify which integrity and confidentiality levels are allowed, and whether the tool call may proceed. The policy also determines how the result should be labeled.

For example:

1. High-confidentiality data should not be allowed to flow into a `send_email` tool call addressed to an external recipient.

2. A tool call whose result depends on untrusted input should generally produce untrusted output.

3. A sensitive side-effecting tool should be able to reject calls that are influenced by untrusted context.

So the answer to “how do you separate data from instructions?” may be: you do not rely on the model to do that separation. You track provenance and privilege outside the model, and then enforce the security policy at the tool boundary.

[0] In the simplest implementation, confidentiality is assessed with a binary low/high value, however, in a more advanced implementation, confidentiality can be represented as the set of users or principals allowed to learn that information.

Collectively, Alphabet (Google), Amazon, Microsoft, and Nvidia already own approximately 25 - 35% of OpenAI and Anthropic respectively. They already are a part of your portfolio.

I have been working on my own "Digital Twins Universe" because 3rd-party SaaS tools often block the tight feedback loops required for long-horizon agentic coding. Unlike Stripe, which offers a full-featured environment usable in both development and staging, most B2B SaaS companies lack adequate fidelity (e.g., missing webhooks in local dev) or even a basic staging environment.

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?

I think you’re conflating security with compliance.

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.

Thanks for the comment. It actually perfectly illustrates my point. Most people equate GDPR with a "Delete My Account" button, but that’s just the tip of the iceberg.

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.

As a European founder building startups since 2015, I’ve spent a massive chunk of my career navigating the "alphabet soup" of EU regulation: GDPR, DSA, DMA, AI Act, CSRD, SFDR, CBAM... the list is exhausting.

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.

Interestingly, sticking to the "Agent = REPL" mental model is actually what helped me solve those specific scaling problems (sub-agents and shared data) without the SDK bloat.

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.

We're repeating the same overengineering cycle we saw with early LangChain/RAG stacks. Just a couple of months ago the term agent was hard to define, but I've realized the best mental model is just a standard REPL:

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.

It depends on how you define “safer.” Cities have a higher frequency of accidents, but with lower severity. Highways have a lower frequency of accidents, but with higher severity.

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

I agree, LLM translations are not only more convenient but also much more capable. I often find myself giving instructions on how to translate text, such as asking the LLM to use formal language in the target language or to apply specific gender-neutral wording. Additionally, it can translate text while preserving the structure (e.g. values in a JSON object) or even adapt to a new target structure. It's just so much more convenient.

Lemonsqueezy, Gumroad, and Paddle also act as the merchants of record, meaning they assume liability for every transaction. Their role extends beyond simply handling invoicing.

While I agree with your statement and recognize that, for now, Perplexity has only introduced a financial information platform comparable to Google Finance or Yahoo Finance, the true value of any forward-looking financial model is rooted in the depth of the qualitative research supporting it.

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.

The international business class is simply inferior to most of its competitors. Other airlines offer larger seats (4 seats per row vs. 6 seats per row). Their onboard entertainment systems use more modern hardware, provide a better selection of content, and sometimes even integrate better with personal devices. The culinary options are less refined. Additionally, Lufthansa still charges $27 for in-flight Wi-Fi. Their lounges are also subpar — smaller, more crowded, and with fewer culinary options. This is based on my personal experience flying with Lufthansa, Austrian, Swiss (all part of the same group), British Airways, Singapore Airlines, and Turkish Airlines. However, other business travelers echo these sentiments. It's noticeable that they enjoy a lack of competition in their home country of Germany, since some healthy competition would force them to actually improve their business class offering.