14. Vertical Agent Pack #2 — The Routine Agent
**Goal:** A generalized scheduled-autonomous-agent template. The user defines what the agent should do, when it should run, and where to deliver the output. The runtime handles everything else. Brand Voice Agent (Section 13) is one specific instance of this pattern; this section defines the broader category.
This is directly inspired by Anthropic's own Claude Routines feature, generalized for the multi-tenant SaaS context of createagent.ai.
14.1 The Pattern
Every Routine Agent follows the same five-step lifecycle:
```
1. WAKE — fires on a schedule (cron) or webhook
2. GATHER — fetches inputs from configured sources (RSS, APIs, MCP servers, files)
3. THINK — Claude reasons over the inputs against a task prompt
4. PRODUCE — generates output (a draft, a report, a decision, an action)
5. DELIVER — sends to one or more channels (email, WhatsApp, Slack, webhook,
auto-publish to platform, save to dashboard)
```
The user-facing builder asks only six questions:
1. What should this agent do? (free text)
2. When should it run? (preset cadences + custom cron)
3. Where should it get its inputs? (sources picker — MCP catalog + URL list)
4. What's the output format? (preset templates: digest, report, post, decision)
5. Where should it send the output? (channels picker)
6. Approval needed before delivery? (yes / no / yes for first 30 days)
That's it. Everything else is handled by the runtime.
14.2 Templates Library
Ship the platform with these pre-built Routine Agent templates. Each is a system prompt + sources + delivery preset stored in `agent_templates` table. Users can deploy any of them in 60 seconds, or fork and customize.
| Template | What it does | Default schedule | Delivers via |
|---|---|---|---|
| **Brand Voice Agent** | Drafts daily social posts in client's voice | 06:30 daily | Email + WhatsApp |
| **Inbox Triage Agent** | Reads overnight emails (via Gmail MCP), drafts replies, flags urgent | 07:00 daily | Email digest |
| **Competitor Watcher** | Monitors competitor sites/news, alerts on changes | Hourly | Slack + Email |
| **KPI Reporter** | Pulls metrics from Stripe / Notion / Sheets, drafts weekly report | Monday 08:00 | Email + dashboard |
| **News Briefing** | Topic-filtered news digest from RSS + News API | 06:00 daily | Email |
| **Lead Enricher** | Overnight enrichment of new CRM leads (via Salesforce/HubSpot MCP) | 02:00 daily | CRM update + summary email |
| **Investor Update Drafter** | Pulls company KPIs, drafts monthly investor email | 1st of month, 09:00 | Email draft |
| **Content Republisher** | Turns YouTube transcripts or blog posts into LinkedIn / Twitter threads | On-demand or weekly | Approval queue |
| **Meeting Prep Agent** | Reads tomorrow's calendar, researches attendees + companies, drafts briefing | 18:00 daily | Email |
| **Compliance Watcher** | Monitors regulator websites (SAMA, NCA, ZATCA, ADGM, DFSA) for new rulings | Daily 08:00 | Email + Slack |
The Compliance Watcher specifically is gold for the GCC market — every bank, fintech, and law firm needs this and most don't have a clean way to do it.
14.3 Data Model (extends Section 3)
Two new tables:
**`agent_templates`** — the marketplace catalog
```
id uuid pk
slug text unique -- e.g. 'compliance-watcher-gcc'
name text
description text
category text -- 'routine' | 'conversational' | 'workflow'
system_prompt text
default_sources jsonb
default_schedule text
default_delivery jsonb
required_mcp text[] -- e.g. ['gmail', 'salesforce']
price_tier text -- 'free' | 'pro' | 'enterprise'
created_by uuid -- platform or community contributor
```
**`agent_runs`** — every scheduled execution logged
```
id uuid pk
agent_id uuid fk
triggered_by text -- 'schedule' | 'api' | 'webhook' | 'manual'
started_at timestamptz
completed_at timestamptz
status text -- 'running' | 'success' | 'failed' | 'awaiting_approval'
input_summary text
output jsonb
delivery_log jsonb -- where it was sent, when, status
tokens_used int
cost_cents int
```
The `agent_runs` table also doubles as your billing source of truth and your customer-facing "what has my agent done lately" dashboard.
14.4 Scheduling Layer
Use Inngest, Trigger.dev, or Supabase pg_cron — pick whichever you find easiest to integrate with your existing Next.js stack. Trigger.dev is probably the cleanest for non-technical setup; pg_cron is the cheapest if you're comfortable with SQL.
The scheduler does one thing: at the configured time, POST to a single endpoint (`/api/agents/:id/run`) with the trigger context. The runtime takes over from there.
14.5 Approval Queue (shared infrastructure with Brand Voice Agent)
Build this once, reuse for every Routine Agent that needs human-in-the-loop. A single `/dashboard/approvals` page in the user's createagent.ai account showing all pending drafts across all their Routine Agents, with approve/edit/reject actions per item. Email and WhatsApp notifications link directly to this page.
After 30 days, users can flip `approval_required: false` on any agent they trust enough.
14.6 Build Cost
Once the runtime (Phases 1–3) is in place: **~7 days of Claude Code work** to ship the Routine Agent template system + 5 starter templates + scheduler + approval queue. Then ~1 day per additional template after that.
The marketplace effect kicks in around the 20-template mark — at that point users start finding templates faster than you can build them, and a community contribution mechanism becomes worth opening up.
---
15. Strategic Architecture Pivot — Build on Anthropic's Primitives
This section was added after the original architecture was drafted, in light of two Anthropic releases that significantly change the build path: **Claude Managed Agents** and the **Memory tool** in the API.
15.1 What Anthropic Has Now Shipped
- **Claude Managed Agents** (beta, header `managed-agents-2026-04-01`). A managed agent harness with four primitives: Agent (model + system prompt + tools + MCP servers + skills), Environment (configured cloud container), Session (a running agent instance), Events (messages exchanged). Built-in prompt caching, compaction, sandboxed bash + file ops + web tools. You don't build the agent loop or the sandbox — Anthropic runs both.
- **Memory tool** (`memory_20250818`). A first-class file-based memory primitive. Claude can `view`, `create`, `str_replace`, `insert`, `delete`, `rename` files in a `/memories` directory that you back with whatever storage you want (Supabase Postgres works fine). Storage is client-side, so you keep multi-tenant isolation under your own control.
- **Skills in the API**. Skills are now a native API concept attached to agents. Same progressive-disclosure pattern Hermes uses, supplied by Anthropic.
- **Claude Code Routines**. Scheduled Claude Code sessions on Anthropic's infrastructure. Not directly usable inside a multi-tenant SaaS (it's tied to Claude Code subscriptions), but the *pattern* validates that scheduled autonomous agents are a category Anthropic is investing in heavily.
15.2 What This Changes
The Phase 1–3 architecture in Sections 3–9 was written assuming you build the agent runtime yourself. Three of the hardest pieces now have native API primitives:
| Hand-built (Sections 3–9) | Native API equivalent | Effort saved |
|---|---|---|
| Custom agent loop in Next.js API route | Managed Agents Sessions | ~1 week |
| Memory Janitor worker + agent_memory table | Memory tool with Supabase storage backend | ~3 days |
| Modal/E2B sandbox integration for tool execution | Managed Agents Environment | ~2 days |
| Skills loader / Level-0 index assembly | Skills in API | ~3 days |
| Compaction logic for long conversations | Built-in compaction | ~2 days |
That's roughly **2.5 weeks of build time eliminated** — and Anthropic maintains the infrastructure for you instead of you babysitting it.
15.3 Recommended Architecture (Revised)
Keep everything from Sections 3–9 conceptually, but implement it like this:
- **Each user-built agent on createagent.ai = one Anthropic Managed Agent**, created once via the Managed Agents API and stored by ID in your `agents` table.
- **Each conversation = one Session** on that agent, scoped to the end-user.
- **Memory** = enable the Memory tool on every agent, back it with a Supabase-backed memory store keyed by `(agent_id, end_user_id)`. The AGENT_MEMORY/USER_MEMORY split becomes two files in the agent's memory directory — Claude manages them automatically.
- **Skills** = use Anthropic's Skills in the API. Your skill marketplace becomes a UI for browsing, installing, and forking skills onto a user's agents.
- **Tools** = enable the built-in tools you want (bash, file ops, web search, web fetch) plus the user's MCP server URLs. No sandbox infrastructure needed — Managed Agents handles it.
- **Scheduling** = Trigger.dev or Inngest fires a cron, your endpoint creates a Managed Agents Session with the routine's task prompt as the first event, streams events back, captures the output, delivers via gateway.
What you still build yourself:
- Multi-tenant web UI, auth, billing (already done)
- The visual agent builder (your edge)
- The gateway service (Telegram, WhatsApp, email — Managed Agents doesn't handle delivery channels)
- The approval queue UI
- The template marketplace
- Vertical pack configurations
15.4 Trade-offs to Be Aware Of
- **Vendor lock-in.** Building on Managed Agents means Anthropic-only. If you want to offer "use your own model" (OpenAI, Gemini, open-source), you'd need to build a parallel runtime for those. For your current customer base — non-technical founders who just want it to work — this is not a blocker. Mention it on a future enterprise tier if a buyer demands multi-model.
- **Beta status.** Managed Agents is in beta. Behavior may shift. Build your runtime with a thin abstraction layer (a `runAgentSession()` function that wraps the API) so you can swap implementations without rewriting the rest of the platform.
- **Pricing visibility.** You pay for the compute Anthropic runs on your behalf. Test 5–10 representative routines to understand the per-run cost before pricing your tiers.
- **Less differentiation at the runtime layer.** If everyone's building on Managed Agents, the runtime stops being a moat. Your moats become UX, vertical packs, marketplace, and gateway breadth — which were always the right moats anyway.
15.5 Revised Build Sequence
| Phase | Original (build-it-yourself) | Revised (build on Managed Agents) |
|---|---|---|
| 1 | Memory layer (4 tables, 1 worker, ~1 week) | Wire Memory tool with Supabase backend (~2 days) |
| 2 | Skills + recall (2 tables, 2 workers, ~1 week) | Wire Skills API + use Memory tool for recall (~3 days) |
| 3 | Gateway + sandbox + MCP (~2 weeks) | Gateway only — sandbox & MCP are built in (~1 week) |
| 4 | Marketplace (~2 weeks) | Marketplace (~2 weeks, unchanged) |
**Original total to ship the runtime: ~6 weeks. Revised: ~3 weeks.**
15.6 Recommendation
Do the revised version. The original build-it-yourself architecture is still valid as a fallback if Anthropic's beta becomes problematic, but the API primitives are stable enough to ship on. Start by building the Memory tool integration this week — it's the smallest piece and proves the pattern. If it works cleanly, port the rest. If it doesn't, fall back to the hand-built approach in Sections 3–9.
Either way, the user-facing product is identical. The user doesn't know or care whether the agent loop runs on Anthropic's infrastructure or yours. They just know their agent remembers them.
---