Publish Window Keeper

What it does

Publish Window Keeper tracks recurring, rate-limited actions -- a publish cap that resets every 24 hours, a marketplace listing that needs reposting every 45 days -- and tells you exactly what's actionable right now versus still on cooldown. It's built for anyone running a recurring, cooldown-gated action: creators publishing against a platform's rolling cap, sellers reposting marketplace listings before they expire, or anyone re-running the same timed task and losing track of when.

Who it's for

Everyday Agents track: people whose daily life includes a recurring action gated by a timer they have to remember themselves. The two example tracked items in the demo are modeled on real cases the builder deals with personally: ElevenLabs Music Marketplace (caps publishing at 5 tracks per rolling 24 hours) and a Craigslist listing (needs reposting roughly every 45 days before it expires). These are clearly labeled example/demo data in the app, not live-synced from those services.

How it works -- Clock, then Priority, then Human-Attention

Deterministic cooldown engine (Clock agent, pure Python date-math, no model call): for each tracked item, compares last_action_at against its cooldown_hours and returns ready or waiting plus exact hours elapsed/remaining. Tracked items are real rows in a Supabase Postgres table, read via a server-only service-role key, never sent to the client. Priority agent: when more than one item is actionable, resolves the conflict deterministically -- overdue-first, not just first-in-list -- so the answer to "what's most urgent" is reproducible, not a coin flip. Human-Attention agent: makes the ACT_NOW-or-stay-silent call. If nothing needs attention, the agent says so instead of manufacturing urgency -- silence is a feature, not a missing feature. Strands Agent layer, deliberately model-agnostic: on top of the three deterministic stages above, a strands.Agent wraps Google's Gemini Developer API through Strands' built-in GeminiModel provider - the same abstraction that would point at Amazon Bedrock in an AWS-hosted deployment. We picked Gemini specifically to demonstrate that Strands' agent orchestration isn't Bedrock-locked: the routing, tool-calling, and grounding logic is identical either way, and swapping the model provider is a config change, not a rewrite. The practical payoff for this submission: it runs end-to-end on Gemini's free tier, with zero AWS account, zero Bedrock model-access request, and zero payment method anywhere - judges and testers can run the live demo with nothing to provision. The agent's system prompt hard-instructs it to ground every claim in the computed statuses it's given as context and never invent an item, status, or duration. Vercel Python serverless backend (api/checkin.py, BaseHTTPRequestHandler pattern) exposes GET /api/checkin (Clock + Priority + Human-Attention, ground truth only, no writes) and POST /api/checkin (same, plus the Strands/Gemini-reasoned natural-language answer). api/items.py handles the write path -- adding a tracked item or marking one done. Next.js App Router frontend, a calm dark ops-console design, renders tracked-item cards and a natural-language "check in" panel ("What should I do today?") that returns a prioritized, plain-English action list. A guided onboarding tour introduces the deterministic-vs-agent split on first visit.

Why it matters

This is the exact shape of an Everyday Agent: it doesn't hand you another app to babysit. It makes the safe call on its own (compute the real cooldown state, resolve conflicts deterministically) and only surfaces when a human actually needs to weigh in -- publish now, or wait, with the honest reason why, grounded in real timestamps rather than a guess.

Built With

• gemini
• nextjs
• python
• react
• strands-agents-sdk
• tailwindcss
• typescript
• vercel