Scheduling a Genie Agent to run the morning ops report before anyone logs in
Most automation makes a report run faster. We wanted ours to run when nobody was around to start it — already sitting in Slack when the team opened their laptops.
For eighteen months, our operations morning report was a person. Every weekday, someone on the analytics team spent the first 90 minutes of their day stitching it together: pull yesterday's orders, join fulfillment status, check the carrier delays, skim a few escalation emails, and drop it into a channel by 8:30. It worked fine most of the time. It fell apart on the days that person was on PTO or buried in something else.
A dashboard wouldn't have fixed that. What fixed it was turning our Genie Space into a Genie Agent and giving it a schedule.
The insight: a Genie Space waits to be asked
A Genie Space is good at answering questions. Someone types "what were units shipped by region yesterday," and it writes the SQL, runs it, and hands back a chart. But it's reactive by design. It does nothing until a person shows up with a question.
The work that actually hurt us wasn't the ad-hoc question. It was the standing question — the same 12 metrics and the same handful of exceptions to check, every morning. Nobody wants to ask a system the identical thing 250 times a year, and "someone remembers to ask it every day" isn't something you can rely on. The mornings it got skipped were the mornings it mattered.
In 2026, Genie Spaces evolved into Genie Agents: same semantic grounding, but now able to take action through MCP tool connections and scheduled tasks, and to reason over unstructured data alongside your tables. The unstructured part mattered more than we expected. Our morning report was never purely SQL — a good chunk of the signal lived in carrier notification emails and a SharePoint folder of escalation notes, which a Space couldn't read at all.
What the manual report cost us
We had four problems, and only one of them was about time.
The 8am scramble. The report blocked the person who made it. Their first and most alert 90 minutes went to copy-paste instead of actual analysis, which is what we'd hired them for.
The skip-on-busy-days gap. The mornings we most needed the report — a carrier problem, a demand spike — were the same mornings the report-maker was too underwater to make it. It went missing right when it was most useful.
The copy-paste drift. Twelve metrics assembled by hand every day is twelve chances to paste last week's number, filter the wrong region, or drop a row. Nobody caught those, because there was nothing to check them against.
The unstructured blind spot. The numbers said shipments were fine. The escalation emails said a regional carrier had paused pickups. The report only showed the numbers, so it read as confident even when it was missing half the story.
The fix: from Space to Agent
We already had a decent Genie Space for operations — clean column comments, a handful of certified metrics, synonyms so "shipped" and "fulfilled" resolved to the same thing. That curation was the hard part, and it was already behind us. Promoting it to a scheduled Agent took an afternoon.
You spin up an Agent from a prompt, scope its tools, and give it a cadence. The instruction we handed it was plain English:
Every weekday at 06:00, produce the Operations Morning Brief:
1. Units shipped, on-time %, and backlog by region for yesterday vs.
the trailing 4-week average.
2. Flag any region where on-time % dropped more than 5 points.
3. Scan the #carrier-alerts channel and the Ops/Escalations SharePoint
folder for pickup pauses or delays. Summarize anything material.
4. Post the brief to #ops-morning. If any flag fires, @-mention the
on-call lead.
We didn't leave the metric definitions to the model. We pinned them as trusted example queries so the Agent reuses the certified SQL instead of re-deriving it each morning:
-- Trusted asset: "on_time_pct" — the certified definition
SELECT region,
ROUND(100.0 * SUM(CASE WHEN delivered_ts <= promised_ts THEN 1 END)
/ COUNT(*), 1) AS on_time_pct
FROM gold.fulfillment_fact
WHERE ship_date = current_date() - 1
GROUP BY regionThe schedule and tool scope are the boring part:
schedule: weekdays 06:00 (America/Chicago)
tools: [unity_catalog_sql, slack_mcp, sharepoint_connector]
The Agent pulls the metrics from Unity Catalog, scans the channel over MCP, reads the escalation notes from SharePoint, and writes one brief from all three. By the time anyone logs in, it's already posted.
What we gained
Speed. Ninety minutes of a skilled person's morning became a three-minute Agent run that finishes before anyone's in the office.
Consistency. It doesn't have busy mornings. The report that used to disappear on the worst days now shows up on those days too, because a crisis doesn't stop a schedule from firing.
Context. The brief now reads the numbers and the escalation notes together. "Midwest on-time down 7 points — regional carrier paused pickups per this morning's escalation thread" is a line the old SQL-only report couldn't have produced.
The honest fine print
An Agent that acts on its own carries risk a Space that waits doesn't. A few things we learned the careful way.
Benchmark before you trust it. We ran the Agent quietly for two weeks against the human-made report and diffed the two. It disagreed on backlog twice, both times because of a grain mismatch we'd otherwise have shipped without noticing. Don't point a scheduled Agent at a live channel on day one.
Scope the tools tightly. Our Agent can read fulfillment data and post to one channel. It can't write to tables, can't DM anyone, can't touch other schemas. If you give an Agent autonomy, keep the blast radius small.
Guardrail the write actions. The @-mention on-call step is the only thing it does that pings a person, and it fires only past a set threshold. If it flagged something every morning, people would mute the channel within a week, and then the real alerts get lost too.
Match the schedule to your data, not the clock. The Agent fires at 06:00, but our fulfillment pipeline sometimes lands at 06:15 — early enough to look done, late enough to be wrong. We added a freshness check: if yesterday's partition isn't complete, the Agent posts "data not ready, holding" instead of a number. Pick the fire time off your data's SLA, not off a round hour.
Takeaway
A Genie Space is a strong analyst that only speaks when spoken to. That's fine for exploration. It's a bad fit for the standing, unglamorous, every-morning work that keeps an operations team running.
None of this took a smarter model or a bigger cluster. It just took noticing that some questions shouldn't need a person to remember to ask them. If you've already curated a good Space, promoting it to a scheduled Agent is a small step — and for the repetitive reports, it's usually the right one.
