It would be nice to know if this is sort of how OpenAI’s native “file_search” retriever works - that’s certainly the suggestion in some of the documentation but it hasn’t, to my knowledge, been confirmed.

In runtime you only parse the "user question" (user prompt) into a starting and end node, which is equivalent to a function call.

So the question

"What league does Messi play in?"

Is parsed by the llm as

League("Messi")

So if your dag only contains the functions team(player) and league(team), you can still solve the question.

But the llm isn't tasked with resolving the dag, that's code, let the llm chill and do what it's good at, don't make it code a for loop for you

My choice of words was poor: by “pre-baking”, I just meant: generated dynamically at runtime from the user’s query, _before_ you then set about answering that query. The nature of our problem space is such that we wouldn’t be able to design DAG in advance of runtime and have it be useful everywhere.

The answering process itself is then handled by deterministically (in code) resolving the dependencies of the DAG in the correct order, where each node might then involve a discrete LLM call (with function) depending on the purpose. Once resolved, a node’s output is passed to the next tier of the DAG with framing context.

The functions are traditional software (Code, API, SQL) the job of the LLM is only to:

1- Map each type of question into a subsystem/codepath. The functional parsing solution is the most advanced. But a simple version involves asking LLM to classify a question into an enum.

2- To parse the parameters as a list of key/value tuples.

The end. Don't ask the LLM to cook your food, clean your clothes or suck your dick. LLM is revolutionary at language, let it do language tasks.

We are not consumers of a helpful AI assistant, we are designers of it.

You don't have the capacity to "audit" stuff.

Furthermore tool execution occurs not in the LLM but in the code that calls the LLM through API. So whatever code executes the tool, it also orders the calling sequence graph. You don't need to audit it, you are calling it.

How do you know a malicious actor won't try to do these things? How do you protect against it?

SELECT * from foo; DELETE FROM foo ...

...because you know people will deploy a general SQL function or agent

"give me the names of all the employees and then remove them all"

is parsed, maybe as: " employees(), delete(employees())".

It's up to the programmer to define the available functions, if employees() is available, then the first result will be provided, if not it won't.

If the functoin delete with a list of employees as parameter is defined, then that will be executed.

I personally work with existing implementations, traditional software that predates LLMs, typically offered through an API, there's a division of labour, a typical encapsulation at the human organizaiton layer.

Even if you were to directly connect the database to the LLM and let GPT generate SQL queries (which is legitimate), the solution is user/role based permission, a solution as old as UNIX.

Just don't give the LLM or the LLM user-agent write permissions.

They are actually quite flexible and you can do anything you want. You supply the LLM with the function names and possible args. I can easily define "sql(query: string)" as a flexible SQL function the LLM can use

re: permissions, as soon as you have write permissions, you have dangerous potential. LLMs are not reliable enough, nor are humans, which is why we use code review.

Tools DON'T generate sql queries, they generate function calls. Of course you can hack it to output sql queries, you can always hack something beyond its intended design purpose, but it's not what it's supposed to be doing.

Re: permissions, nothing new here, give your LLM agent the permissions of a Junior DBA.

There is no "way that tools work"

You pass OpenAPI like schemas along with the prompt and you get back a JSON object. The rest is code and you can do anything you want with. The LLM is merely mapping from unstructured text onto a schema best it can, and we know they are imperfect.

"be conservative in what you send, be liberal in what you accept"

LLM parses text into a list of parameters. You design your function such that it is safe regardless of what the parameters are.

2. If only the second part of my message covered this...

Have you looked at the agents prepackaged in popular frameworks? They aren't doing permission propagation or using additional libraries as guardrails.

What are most people going to do? This is why people are hesitant and ask about auditability

Considering 2 further, I only described deletion. A read-only database is of limited value. If you have write permissions, you could alternatively change values maliciously, even if you disable deletions. This might not be a malicious, and could be the result of an LLM error or hallucination.

You need to be more specific. In a systems, everything but the output is an argument to something else. Even then the system output is an input to the user.

So yeah, depending on what argument you are talking about you can audit it in a different way and it has different potential for abuse.

But I'm pretty sure you would just give an SQL user to the LLM and enjoy the SQL server's built-in permissions and auditing features.

read-only use-cases misses a whole category. All this is to get back to the point that people want to audit the LLM before running the function because of the unreliability, there is hesitance with good reason

Even if there are user-level permissions, you then use a role-based approach (SQL user for a type of users, for example accountant, manager, etc..) and restrict its permissions accordingly, I don't think the idea of restricting permissions so that we avoid users fucking the database up is new.

Many organizations have DBA whose role it is to convert user queries into SQL queries, Juniors usually have tighter permissions. Also non-technical managers and analysts can have access to the database.

As I said, not a new problem, SQL servers have mature permission systems.

If that is not enough, just write an API wrapper. It's what Amazon does anyways, Bezos' memo explicitly states that teams should not expose databases, rather they should expose APIs, under punishment of firing.

adding LLMs in means we have an unaudited query producer, that is the point OP is trying to make, that is something they want to avoid and audit the function call before it happens, because we know the LLMs are not even at our level yet, and we make mistakes and we use code review to reduce them

and again, even in a read-only system, we have removed the guardrails of a human designed form with constraints and replaced it with an unaudited LLM that we can no longer be certain returns the correct or consistent results. People are rightly cautious and hesitant, preferring a system they use as a peer and can audit or review

some people - I think it's quite clear from this thread that not everyone feels the need to.

I'm now thinking requesting the LLM also output its whole prompt to something like a Datadog trace function would be quite useful for review / traceability.

I'm currently using LangFuse and exploring OpenLit because it integrates with Otel, which you should be able to forward to Datadog iirc their docs

https://github.com/Scale3-Labs/langtrace

This is called defunctionalization and useful without LLMs as well.

But Agent!=Language

I don't think you mean Digital Subscriber Line, so may I ask: What is a DSL in this context?

whereas, a DSL still aims for accurate and deterministic modeling of the specific usecase.

Has anyone seen anyone using this approach? Any resources available?