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 agy CLI (our IDE + agent host)
  • uv / uvx — for the DuckDuckGo search server (Lab 1); the offline mock-search server is the fallback

Not sure? Run the setup-check script (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:

  1. Specify — write the machine-readable requirements (BMAD docs)
  2. Harness — expose only the capabilities the agent may use (MCP)
  3. Generate — let the agent build across IDE, terminal, browser
  4. Self-correct — the agent reads errors and fixes its own output
  5. Deploy — provision live infrastructure via Cloud CLIs
  6. 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 + agy CLI)
  • Harness: custom Node.js MCP server + MCP Inspector
  • Runtimes: Node.js v20+, npm / npx
  • Search: DuckDuckGo MCP (uvx) · offline mock-search fallback
  • 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.

FACILITATOR (presenter note, not shown): Cold open — land this before the title sinks in. Don't rush it.

FACILITATOR (presenter note, not shown): keep this to a minute — energy stays on the build, not the rules.