Median insert-to-queryable latency on your core events hypertable jumped to 14 seconds over the last 90 minutes, well above the trailing-7-day ~2.8s baseline. The spike correlates with a continuous aggregate refresh backlog. Handing off to Fi to confirm root cause.
An agent watches one thing and acts on it. Not a workflow, just a standing watch that usually does nothing and acts the moment it should.
An agent does what you'd do, and only what you've authorized.
It acts on the same governed metrics as your dashboards, and every action is logged and traceable.
It alerts and recommends on its own; anything that changes data is yours to approve.
Point a new agent at a throwaway channel and watch its judgment before it touches anything real.
It remembers what it already flagged and waits before acting again, so it won't alert you about the same thing twice.
It computes the metric off your live Timescale hypertables and checks it against the same metric in your warehouse or downstream models, then flags the gap before anyone presents it. So the count in your application and the count on the dashboard are the same number, and you find the drift yourself instead of during a review.
When a metric goes sideways for a data reason (a null spike in a time column, a chunk that stopped receiving inserts, a row count that fell off a cliff after a schema change), it flags the anomaly and, with your approval, writes the finding back to a warehouse table your pipeline already reads. The signal lands where the rest of your stack already looks.
Point it at a metric you care about (request latency, event throughput, sensor readings, whatever your hypertables describe) and it watches on your schedule. When it breaks trend, it tells you which segment moved and by how much, then hands off to Fi to investigate the why across the data it can see.
Beyond alerts and write-backs, an agent can run arbitrary Python, so it can do whatever the task actually requires: call an API, kick off a job, reshape a result set, or wire into your own tooling. The SQL it runs is inspectable and the action space is yours to define.
You could rig one of these with a cron job and a Slack webhook in an afternoon. The watching is the easy part. Here's what you'd own forever, and don't, here:
Every TimescaleDB object, modeled and query-ready the moment you connect.
It runs on your real Timescale instance (hypertables with irregular chunk intervals, half-documented views, continuous aggregates that haven't been refreshed in weeks), not a tidy demo. You define the metric once as governed SQL and it watches that.
A message in the channel you choose, with the context and a button to act on it.
A summary in the inbox of the people who need to see it.
A payload to your own systems, to wire the agent into whatever you already run.
A flag written back to your warehouse for everything downstream to pick up.
Kick the question to Fi to investigate the why and propose the fix.
Expose it to your own agents and tools over MCP, and drive it from your stack.
Run it in your own VPC or fully self-hosted. Everything it does is pure SQL and Python you can inspect.
Fi is your AI analyst. It helps you build and customize everything in Definite, including the agents that watch and act.
Your AI analyst. Ask questions in plain English, and let it help you build and customize everything in Definite, including your agents.
Meet Fi →The watchers and actors. Once you've built one, it runs on its own, keeping an eye on what matters and acting the way you would.
Autonomous agents →