Power-User Capstone 2: Ship a Scheduled Agent
Assemble the week into one small, running agent
You'll be able to
- Combine builder, actions, a schedule, and versioning into one shipped agent
- Tie the agent's value to a measured business outcome
Read first
Day 7 Lab
**Status: Generally available β Gleanβs Agent Builder and its core features (scheduled triggers, versioning, native actions) are GA. Only the *content triggers* trigger type remains Beta; confirm availability in your tenant.**
- Vibe-code one small agent from a single sentence (Day 1), then tighten its steps (Day 2).
- Wire each step to the right native action β reads freely, writes only with a guard (Day 3).
- Attach a schedule with an empty-run no-op and a loud failure path (Day 4).
- Save it as a named v1 with a one-line changelog, so the change is reversible (Day 6).
- Pick the single metric you'll watch to decide if it earns its keep β then ship it.
Working Example: One Shipped Scheduled Agent
This capstone assembles the week's announced building blocks β builder, actions, schedule, versioning β into one running agent. Verified against fall25_launch.
Agent: "Daily unowned-ticket nudge" (shipped, v1)
Trigger schedule: weekdays 09:00, window = since last run
Loop open Jira tickets with no owner (cap 25/run)
Step 1 Jira get_issue (read)
Step 2 infer likely owner from component
Step 3 Slack post_message (write, guarded: suggest only, no auto-assign)
Guard no unowned tickets -> send nothing
On error DM #ops-alerts
Version v1 saved, changelog: "initial ship"
Metric watched: time-to-owner on new tickets (down = the agent is earning its keep).
The case study to anchor on is Super.com, which reported real, measured gains from Glean adoption β the point of a capstone is to tie a shipped agent to an outcome like that, not to ship for its own sake. (For scale, Glean's launch cited Zillow running on the order of 3,400 agents β but scale without a metric is just count.) Choosing and watching that one metric is the MANAGE discipline that decides whether an agent stays. Everything here rests on Fall '25 announcements: before you ship for real, confirm the builder, actions, schedule, and versioning are GA in your tenant.
Case Study: Super.com
Super.com's results with Glean are the model for this capstone: adopt a capability, point it at a concrete workflow, and measure the outcome rather than the activity. Verified against case_supercom_glean.
Check for understanding
Name the one metric you'd watch to decide whether your shipped agent is actually worth keeping.
Check yourself
1. In Glean's vibe-code agent builder, how do you start building an agent?
2. The vibe-code builder, 100+ native actions, scheduled triggers, looping, and versioning are best described as...
3. Before adding a native WRITE action (e.g., update a Salesforce case) to an agent step, what should you check?
4. An agent runs unattended on a daily schedule. Which guard most directly keeps a bad run from compounding?
5. Why does rolling an agent back to a known-good version count as a governance control?
In 10 seconds
βCapstone: vibe-code a small agent, give it native actions, a schedule, and a saved version β then ship it. Anchor it to a real outcome the way Super.com did with Glean.β
The Developer Platform and Typed Clients