From Prompts to Autonomous Systems with MCP & Spec-Driven Development
Agentic AI Architect
From Prompts to Autonomous Systems with MCP & Spec-Driven Development
A 2-Day Technical Workshop · Technovate Hub
GITS, Udaipur · June 18–19, 2026
AICTE Indovation Centre, Jaipur
Before Anything Else
Right now, you can ask an AI to write code.
By 5 PM tomorrow you'll have built the system that decides what an AI writes — an MCP server an agent calls, a pipeline you broke on purpose and then hardened, and a spec-driven app, shipped live.
The engineer who uses AI and the one who architects it are not the same person.
This is the room where you cross over.
The One Idea for These Two Days
You will learn the difference between building with AI and building AI systems.
By the end, you won't just use an agent. You'll have built one — and shipped it live.
Breaking the Title
Three words. Each one is a promise.
Agentic — AI that acts, not just talks. It perceives, decides, acts, and remembers — in a loop.
Architect — not a coder, not a prompter. You design the system: its rules, its limits, what it's allowed to do.
The title is the thesis: Design autonomous systems — don't just use them.
The Central Distinction
Building with AI vs. Building AI Systems
This is the line everything else hangs on.
Building with AI
What most people already do:
- Open a chat / Copilot → type → get code → paste → fix → repeat
- The AI is a tool you operate
- You are the loop — you read, decide, and feed back every step
- It works, but it doesn't scale: every action needs you in the chair
The intelligence is rented — one prompt at a time.
Building AI Systems
What this workshop teaches:
- You construct the machinery around the model
- The loop, the tools it can call, the rules it must obey, the surfaces it runs on
- The AI becomes a component inside a system you engineered
- You built the loop — you no longer are the loop
The system runs, self-corrects, and deploys — you supervise the architecture.
Say It in One Line
Building with AI: you hold the AI and do the work.
Building AI systems: you build the thing that holds the AI — and it does the work.
The Analogy
Using AI = driving the car.
Building AI systems = engineering the self-driving stack:
- Sensors → Perception
- Decision logic → Reasoning
- Actuators → Action / Tools
- Maps it remembers → Memory
What These Two Days Are
- A systems engineering workshop — AI is the material you build with and around
- A move from stochastic (hope the prompt works) to deterministic (define the constraints)
- Hands-on — 5+ hours of building; you leave with a deployed full-stack app
- A study of the full stack of agency: protocol (MCP), method (Spec-Driven Development, via BMAD), surfaces (IDE, Terminal, Browser, Cloud)
What These Two Days Are Not
- Not a prompt-engineering course — we're past "write better prompts"
- Not "vibe coding" — we diagnose why it collapses, then cure it
- Not model training or ML theory — no gradients, no neural nets
- Not a passive demo — nobody leaves having only watched
Where You Are → Where You'll Be
| Right now (most of you) | By 5 PM Sunday |
|---|---|
| You use AI — prompt, copy, paste, hope | You've built an MCP server an AI calls |
| You consume tools other people made | You broke an agent pipeline, then hardened it |
| "Vibe coding" — fast, then it collapses | You spec-drove a real app, reviewed against the spec |
| A power user of AI | An architect of AI systems |
No prior agent experience assumed — JS/TS + Git is enough. If you want the right-hand column, you're in the right room.
The Two-Day Arc
Day 1 — The Mechanism How an agent works. Take apart the agent loop; build the MCP harness that lets AI safely touch real systems.
Day 2 — The Method How to direct it well. Stop coding line-by-line; write machine-readable specs (BMAD) that drive an agent across the IDE, terminal, browser, and cloud.
Day 1 gives the agent hands. Day 2 gives it marching orders.
The Finale (Where We're Headed)
A single English sentence —
flows through the system you built, securely updates your data layer, and renders live on a production URL.
That's the proof: you didn't use a system. You built one.
The Capstone: StackLog
A secure, auditable full-stack developer journal.
- React frontend
- Express / SQLite backend
- A custom, independent MCP data-isolation layer
You build it. The agent helps. You stay the architect.
Day 1 — At a Glance
| Time | Block |
|---|---|
| 09:30–10:45 | From Stochastic Parrots to Autonomous Loops |
| 11:00–12:30 | Deep Dive into the Agentic Harness (MCP & CLIs) |
| 13:30–16:15 | Lab: Building the StackLog Data Layer |
| 16:15–17:00 | Day 1 Retro & Cloud Authentication Pass |
Day 2 — At a Glance
| Time | Block |
|---|---|
| 09:30–10:45 | Failure Modes of Vibe Coding & The SDD Solution |
| 11:00–12:30 | The BMAD Framework Walkthrough |
| 13:30–16:00 | Lab: Multi-Surface Generation & Infra Sprint |
| 16:00–16:45 | Spec Drift & The CLI Automation Layer |
| 16:45–17:00 | Closing Loop Showcase & Handoff |
Before We Start — Tool Check
Four things (the setup-check script verifies them):
- Node.js LTS v20+ — with
npm/npx(the MCP server + the Day-2 app) - Git + a GitHub account — you push your repo as the portfolio artifact
- Google Antigravity — the App and the
agyCLI (our IDE + agent host) uv/uvx— for the DuckDuckGo search server (Lab 1); the offlinemock-searchserver is the fallback
Not sure? Run the
setup-checkscript (course site → Resources) — it checks all of this in ~10 seconds and installs what it can.
The public nomination mentioned VS Code, Claude Desktop, Copilot, Ollama, and cloud accounts. You don't need them here: the host is Antigravity (a VS Code fork), search is DuckDuckGo / mock-search, and the Day-2 app runs locally (
:3000/:3001).
Housekeeping — 60 Seconds
Timing — reporting 09:00; sessions 09:30–17:00 both days; morning, lunch, and afternoon breaks (see the At-a-Glance slides).
Wi-Fi — connect now; it can wobble mid-lab. Every lab has an offline fallback (e.g. mock-search), so the network never blocks you.
The lab social contract
- Pair up — stuck for >5 min? Ask your neighbour before us.
- Breaking things is the point — Lab 3 literally asks you to break your agent.
- Keep your repo pushed — it's your portfolio artifact by Sunday.
- Flag blockers loud and early.
How We'll Think About All of This
Three questions frame the entire workshop:
WHY → Principles The beliefs that decide what good looks like.
WHAT → Framework The structure those principles take shape in.
HOW → Process + Methods + Tools The concrete way we execute it, day to day.
Most courses teach only the How. We start with Why, so the How makes sense.
WHY — The Principles
The beliefs everything else is built on
If you forget every command and config from these two days, keep these.
Principle 1 — Determinism over Hope
A system you can't predict is a system you can't trust.
- "Vibe coding" hopes the prompt works
- Engineering defines the constraint so the outcome is guaranteed
- We trade stochastic luck for deterministic behavior
If you can't say what the system will do before it runs, you haven't designed it yet.
Principle 2 — The Human Designs, the Agent Executes
Your value moves up the stack.
- You stop being the one who types every line
- You become the one who defines the rules of the game
- The agent does the labor; you own the architecture
Promotion, not replacement: from coder → architect.
Two Modes of Directing
Once you stop typing every line, directing the agent splits into two modes:
- Conductor — hands-on, real-time. You're in the loop on each change, keeping fine-grained control. Best for tricky logic or unfamiliar code. (Lab 2 feels like this.)
- Orchestrator — async, higher-level. You define the goal, hand it off, review the result. Best for well-specified work. (Lab 3 — and all of Day 2 — feel like this.)
The orchestrator's skill set: specify · decompose · evaluate · design the constraints. The better your spec, the more you can safely orchestrate.
Principle 3 — Constrain the Power
An agent that can do anything is a liability, not a feature.
- Give the agent exactly the capabilities it needs — no more
- Every tool it can call is a door you chose to open
- Security and auditability come from what you refuse to allow
Power without boundaries isn't autonomy — it's risk.
Principle 4 — Specification is the Source of Truth
The spec is the product. The code is a by-product.
- Machine-readable requirements drive the build
- When code and spec disagree, the spec wins
- Documentation stops being an afterthought and becomes the input
You don't write code and document it later. You write the spec, and the code follows.
WHAT — The Framework
The structure the principles live in
Principles are beliefs. The framework is the shape they take.
The Framework: Two Halves of One System
The Harness (MCP) — the agent's hands A controlled execution layer connecting the model to real systems: filesystems, runtimes, databases — over structured JSON-RPC.
The Method (BMAD) — the agent's marching orders A spec-driven framework of machine-readable documents and defined personas that direct what the agent builds.
Harness without method = power with no direction. Method without harness = direction with no power.
The Framework Layer 1 — MCP
Model Context Protocol — the open standard for agent capability.
- Defines how an agent discovers and calls tools
- A clean separation: Host ↔ Client ↔ Server ↔ Resources
- Portable — your server works with any MCP client, not one IDE
MCP is the plumbing. It decides what the agent is allowed to touch.
The Framework Layer 2 — BMAD (our SDD method)
Spec-Driven Development is the discipline. BMAD is how we do it — a multi-document, persona-driven specification method.
The four pillar documents:
- PRD — what we're building and why
- Tech Spec — how it's structured
- Story Map — the units of work
- Task List — the executable steps
The three personas:
- Architect — designs · Builder — implements · Reviewer — verifies
BMAD is the blueprint. It decides what the agent should build.
HOW — Process, Methods & Tools
Turning the framework into action
This is the day-to-day mechanics — what you actually do.
HOW · The Process
The end-to-end loop we follow:
- Specify — write the machine-readable requirements (BMAD docs)
- Harness — expose only the capabilities the agent may use (MCP)
- Generate — let the agent build across IDE, terminal, browser
- Self-correct — the agent reads errors and fixes its own output
- Deploy — provision live infrastructure via Cloud CLIs
- Verify — a Reviewer agent checks output against the spec
Specify → Harness → Generate → Self-correct → Deploy → Verify.
HOW · The Methods
The specific techniques inside the process:
- Spec-Driven Development (SDD) — specification before synthesis
- Tool-schema design — bulletproof JSON schemas to kill hallucination
- The multi-surface control loop — agent works natively across IDE, Terminal, Browser, Cloud
- Spec-drift detection — feeding
git diff+ spec to a Reviewer to catch silent regressions
Methods are how each step of the process is done well.
HOW · The Tools
The concrete stack you'll operate:
- IDE / App: Google Antigravity (App +
agyCLI) - Harness: custom Node.js MCP server + MCP Inspector
- Runtimes: Node.js v20+, npm / npx
- Search: DuckDuckGo MCP (
uvx) · offlinemock-searchfallback - Build target: React + Express + SQLite (StackLog) — run locally
- Codegen: the Antigravity agent (Copilot Chat = optional fallback)
Tools are replaceable. Principles are not.
Putting It Together
| Lens | Layer | The question it answers |
|---|---|---|
| WHY | Principles | What does "good" even mean? |
| WHAT | Framework (MCP + BMAD) | What structure do we build in? |
| HOW | Process · Methods · Tools | What do we actually do? |
Learn the Why once, and the How becomes obvious. Learn only the How, and it breaks the moment the tools change.
The Agentic Architect Vocabulary
One shared language for two days
If you know these words, you can follow everything that follows.
Vocabulary · Foundations
- LLM — a model that predicts the next token; the raw "brain," no hands.
- Token — the smallest chunk of text a model reads or writes.
- Inference — a single run of the model turning input into output.
- Context window — the model's short-term memory; everything it can "see" at once.
- Prompt — the instruction you give the model.
- Hallucination — confident output that is simply wrong or invented.
- Stochastic — probabilistic; same input can give different output.
- Deterministic — predictable; defined input gives a guaranteed result.
Vocabulary · From Chat to Agents
- Chat — you ask, it answers; you do all the work between turns.
- RAG — Retrieval-Augmented Generation; the model reads fetched documents before answering.
- Agent — an LLM that runs in a loop and acts on the world.
- Agent loop — Perception → Reasoning → Action → Memory, repeated.
- Autonomy — the system takes steps without you driving each one.
- Tool / tool call — a function the agent can invoke to do something real.
- Memory — what the agent carries between steps or sessions.
Vocabulary · The Harness (MCP)
- MCP — Model Context Protocol; open standard for giving agents tools.
- Host — the app the user interacts with (the IDE, the chat client).
- Client — the connector inside the host that speaks MCP.
- Server — the program you build that exposes tools and data.
- Resource — the real thing behind a tool: a file, DB, or runtime.
- JSON-RPC — the structured request/response format MCP speaks over.
- Tool schema — the JSON contract defining a tool's name, inputs, and outputs.
- MCP Inspector — a dev tool to watch and test raw MCP traffic live.
- Transport layer — the channel (stdio, HTTP) carrying MCP messages.
Vocabulary · The Method (BMAD & SDD)
- SDD — Spec-Driven Development; write the spec before any code.
- BMAD — the multi-document, persona-driven specification framework.
- PRD — Product Requirements Document; what we build and why.
- Tech Spec — how the system is structured and built.
- Story Map — the work broken into user-facing units.
- Task List — the concrete, executable steps.
- Persona — a fixed agent role with a rigid system prompt.
- Architect / Builder / Reviewer — the three personas: design, implement, verify.
- Source of truth — the spec; when code disagrees, the spec wins.
Vocabulary · Surfaces & Self-Correction
- Surface — a place the agent operates: IDE, Terminal, Browser, Cloud.
- Multi-surface control loop — one agent acting natively across all surfaces.
- IDE — where the agent reads and writes code.
- Terminal — where the agent runs commands and reads errors.
- Self-correction — the agent reading its own failure and fixing it.
- Vibe coding — unstructured, chat-driven generation with no spec.
- Spec drift — code silently diverging from what the spec requires.
- Regression — a change that quietly breaks something that worked.
Vocabulary · Deployment & Tooling
- CLI — Command-Line Interface; text commands an agent can run deterministically.
- Cloud CLI — Vercel / Railway / Cloudflare tools that provision live infra.
- Provision — to create and configure live infrastructure on demand.
- Headless — a script that runs with no UI, ideal for automation.
git diff— the exact set of changes between code versions.- Antigravity — the IDE/App + CLI surface used for the Day 2 sprint.
- Ollama — runs an LLM locally; a common offline-model option (not part of our stack — search uses DuckDuckGo /
mock-search). - StackLog — the capstone app you build across both days.
Five Words to Anchor Everything
Agent runs the loop. MCP gives it hands. BMAD gives it orders. Surfaces are where it works. Spec is the truth it answers to.
Let's Begin
From prompt consumers → systems engineers.
Day 1 starts now: the anatomy of an agent.