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!
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.
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.
An interesting thought experiment is that a service that can both be triggered by, and write to, the
same persistent queue can call an LLM in each iteration and create a self-evolving agentic workflow. Much like a Scrapy spider can recursively find new things to crawl, an agent can recursively find new things to do.
SQL is a great language to express “choose something from a priority queue and do something with it” but if you try to think about predefining your entire computation DAG as a single query rather than many queries over time, you lose the loose asynchronous iteration that gives an agent the same grace you’d give to a real-life task assignment. And that grace is what makes agentic workflows powerful.