Agents: the agent SDK, managed agents, and scheduling, MBA Training, MBA Training

python

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions, tool, create_sdk_mcp_server

@tool("run_sql", "Run a read-only SQL query against the analytics DB", {"sql": str})
async def run_sql(args):
    rows = await analytics_db.fetch(args["sql"])
    return {"content": [{"type": "text", "text": str(rows)}]}

@tool("post_to_slack", "Post a message to the #metrics channel", {"text": str})
async def post_to_slack(args):
    await slack.post(channel="#metrics", text=args["text"])
    return {"content": [{"type": "text", "text": "posted"}]}

tools = create_sdk_mcp_server(name="report-tools", tools=[run_sql, post_to_slack])

PROMPT = """Pull yesterday's signups, revenue, and active users from the
analytics DB. Compare each to the prior day. Write a 5-line report that
leads with anything unusual, then post it to Slack."""

async def main():
    options = ClaudeAgentOptions(
        mcp_servers={"report": tools},
        allowed_tools=["mcp__report__run_sql", "mcp__report__post_to_slack"],
        system_prompt="You are a careful analytics assistant. Query before you conclude.",
    )
    async for message in query(prompt=PROMPT, options=options):
        print(message)

asyncio.run(main())

Scheduling: making it run on a cadence

An agent that you trigger by hand is a demo. An agent that runs every night at 2am while you sleep is a product. Scheduling is the difference.

There is no magic here, and that is good news: an agent run is just a process you can invoke. Pick the trigger mechanism that matches where the agent lives.

Option 1: OS cron (self-hosted). If the agent runs on a server you control, plain cron is fine. One line in your crontab:

bash

0 2 * * * cd /opt/nightly-report && /usr/bin/python3 agent.py >> /var/log/report.log 2>&1

That runs agent.py at 02:00 every day and appends output to a log. Simple, durable, and you can read the log when something looks off.

Option 2: A serverless scheduled function. A cloud scheduler (a scheduled Lambda, a Cloud Run job, a GitHub Actions schedule trigger) invokes the agent on a cron expression without you keeping a server alive. You pay only when it runs. This is the sweet spot for most nightly jobs.

Here is the GitHub Actions version, which is genuinely the easiest if your code already lives in a repo:

yaml

name: nightly-report
on:
  schedule:
    - cron: "0 2 * * *"
  workflow_dispatch: {}   # lets you trigger it manually too
jobs:
  run:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with: { python-version: "3.12" }
      - run: pip install claude-agent-sdk
      - run: python agent.py
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

The workflow_dispatch line is a small but important habit: it gives you a manual "run now" button so you can test without waiting until 2am. Store your key as a repository secret, never in the file.

Option 3: Managed agents with a schedule. When you run the agent on Anthropic's managed infrastructure, you attach a schedule to the agent definition rather than wiring up your own cron. The agent loop, retries, and execution environment are handled for you; you provide the cadence and the trigger. Check the current Agent SDK docs for the exact configuration, since the managed surface is evolving quickly through 2025 and 2026.

What changes once it runs unattended

A scheduled agent is autonomous, which raises three concerns a one-off call never had. Design for them from day one.

Idempotency and partial failure. If the agent posts to Slack but the run crashes afterward, will tomorrow's run double-post? For a report this is harmless, but for anything that writes data, make tool actions safe to retry or check whether the work was already done before doing it.

Observability. You are not watching. Log every tool call and the final outcome, and have the agent itself signal success or failure in a place you will see (a Slack thread, a status row). If the nightly report stops appearing, that absence should be loud.

Cost and runaway loops. An agent in a loop can, in pathological cases, call tools far more than you expect. Set a turn or budget limit so a confused agent stops instead of running for an hour. The Agent SDK lets you cap this; use it.

Least privilege. This is worth repeating because it is the cheapest insurance you have. The nightly agent gets a read-only database role and a single Slack channel. Nothing more. An unattended agent should never hold permissions it does not strictly need for its one job.

Key Takeaways

Use an agent when the steps depend on what Claude discovers. If you can script the exact sequence, a single Messages API call is simpler and cheaper. If you cannot, the loop earns its place.
Let the Agent SDK own the loop. Your job is defining tools (often over MCP), writing one clear instruction, and setting permissions. Prototype self-hosted, then move to managed agents when you want Anthropic to handle the runtime.
Scheduling is just a trigger on a normal process. OS cron for a server you own, a scheduled serverless job or GitHub Actions schedule for most cases, or a schedule attached directly to a managed agent.
Design for unattended operation explicitly: make write actions idempotent, log every tool call so failures are loud, cap turns to prevent runaway loops, and grant least privilege so the agent can only touch its one job.
Always include a manual trigger (workflow_dispatch, a "run now" path) so you can test the agent without waiting for the schedule to fire.

Agents: the agent SDK, managed agents, and scheduling

When an agent beats a single call

The Claude Agent SDK in plain terms

Managed agents vs. running it yourself

A concrete example: the nightly report agent

Scheduling: making it run on a cadence

What changes once it runs unattended

Key Takeaways