Dev.to AI 🤖 Ai 👁 0 📖 3 min read

Show DEV: an 8-module course in which you ship an AI agent, an approval queue and your own MCP server

Disclosure up front: this is our product. I'm Yusuf, founder of Homingo, and this is a paid course I made: ₹1,499 one-time (about US$17; international cards are accepted). The problem it is built around Most

Disclosure up front: this is our product. I'm Yusuf, founder of Homingo, and this is a paid course I made: ₹1,499 one-time (about US$17; international cards are accepted).

The problem it is built around

Most agent tutorials end at a chat loop: a prompt, a model call, a tool call, a nice demo. Then the agent gets permission to send an email or write to a database, and the hard questions start. What stops it from running the same action twice? What if the payload changes after someone said yes? Who checks the draft before it goes out? Which job ran at 3 AM, and can you pause it?

Homingo runs on a system built to answer those questions. The course teaches each piece from the part of that system it comes from.

The approval step, in one example

Here is the heart of the idea, simplified from a small Python + SQLite demo we built to show the course. Every proposed action is stored with a hash of its payload. Approving it re-checks two things before anything runs:

def approve(action_id):
    kind, body, sha, status, done_at = db.execute(
        "select kind, payload, sha, status, done_at from actions where id = ?",
        (action_id,)).fetchone()
    if status == "done":
        print(f"#{action_id} already ran at {done_at}. Skipped.")
        return
    if hashlib.sha256(body.encode()).hexdigest() != sha:
        print(f"#{action_id} payload changed after review. Refused.")
        return
    # ... perform the action, then write the audit row and mark it done

This excerpt is the single-worker case. With concurrent approvers you would claim the row atomically first (an UPDATE ... WHERE status = 'pending' and a check of the affected row count) before acting.

Approve twice and the second call is a no-op. Edit the payload after review and it is refused. In the course you build the full version: a queue where only an approved, unchanged payload can execute, exactly once, with an audit trail.

What you build, module by module

  1. Project setup and secrets hygiene: keys out of git, typed settings that fail fast, one logged and retried model client.
  2. The agent loop: bounded and traced, with step, token and time limits and a recorded stop reason.
  3. Tool use and structured output: typed tools, JSON validated against a schema.
  4. Human-in-the-loop approval: the queue above, done properly.
  5. Building an MCP server: your tools over the Model Context Protocol, tested with Claude and other MCP clients.
  6. Reviewer models and QA gates: a second model that did not write the draft scores it before it goes out.
  7. Scheduled jobs in production: idempotent runs, run logs, a pause switch.
  8. Deploy and demo.

Every module is a short video lesson, an MCQ check and a hands-on coding round. The capstone is your own agent and MCP server in a public GitHub repo with a live demo, and you get a certificate of completion from Homingo. Level: intermediate, for people comfortable writing code.

Watch a full lesson first

The MCP lesson, "Building an MCP server: one set of tools, every client", is open to everyone in full, no sign-in. The whole syllabus is on the same page:

https://learn.homingo.co.in/courses/build-ship-ai-agent-mcp-server?utm_source=devto_showdev&utm_medium=post&utm_campaign=course1#preview

If you are building agents that touch real systems, I'd like to hear which of these steps you've found hardest to get right.

📰 Read the original article on Dev.to AI

Originally published by Dev.to AI. Aggregated on AIWithGhost for educational purposes — full credit and traffic to the original publisher.