This combines a bunch of different things, but the key idea appears to be having a Flink (stream processing server) SQL query set up that effectively means that new documents added to the data store trigger a query that then uses an LLM (via a custom SQL function) to e.g. calculate a summary of a paper, then feeds that on to something that sends an alert to Slack or similar.
So this is about running LLM prompts as part of an existing streaming data processing setup.
I guess you could call a trigger-based SQL query an "agent", since that term is wide open to being defined however you want to use it!
gunnarmorling · 1h ago
Author here, thanks for reading and commenting! Indeed my conclusion is that "agent" means different things to different people. The idea for this post was to explore what's there already and what may be missing for using SQL in this context. When following Anthropic's taxonomy, as of today, SQL let's you get quite far for building workflows. For agents in their terminology, some more work is needed to integrate things like MCP, but I don't see any fundamental reasons for why this couldn't be done.
philipodonnell · 4h ago
I’ve built lots of pre-LLM data processing pipelines like this and the more I read people putting “agents” into this kind of context the less they resemble agents like the Anthropics of the world defines and the more they just resemble functions. I wonder if eventually there won’t be a distinction and it’ll just be a way to make processing and branching nodes in a pipeline less deterministic when you need more flexibility than pure code-rules can give you.
nilirl · 4h ago
This felt forced.
If you read through the whole thing, they don't manage to build an AI Agent, they make LLM API calls using Flink's SQL.
They admit making it agentic, with choice over tool selection and with agent-like memory, requires workarounds.
Annoying workarounds, imo.
The post mentions work is in progress to build agents that use Flink without using Flink SQL.
Thereby invalidating it's own title.
esafak · 4h ago
Perhaps a charitable take is that this is a musing on how to use immutability for building agents? Maybe a functional approach would be less constrictive than SQL.
tra3 · 4h ago
Indeed. I'm very curious about the original source of inspiration for the post, "That microservice should have been a SQL query". It's not as catchy without AI though.
So this is about running LLM prompts as part of an existing streaming data processing setup.
I guess you could call a trigger-based SQL query an "agent", since that term is wide open to being defined however you want to use it!
If you read through the whole thing, they don't manage to build an AI Agent, they make LLM API calls using Flink's SQL.
They admit making it agentic, with choice over tool selection and with agent-like memory, requires workarounds.
Annoying workarounds, imo.
The post mentions work is in progress to build agents that use Flink without using Flink SQL.
Thereby invalidating it's own title.