BETA · Launching on August 1. Stay tuned for updates.
BYSHASHANKEVENTSMSRITEXPLAINER
← MSRIT

THE KEYNOTE, WRITTEN DOWN

Agentic AI in the Real World.

Orchestrating agents and humans at work — every idea from the talk, in writing, for whenever you need it back.

FDP · MSRIT · 13 JULY 2026

Slides are backdrops — I never read from them, and you shouldn't have to photograph them. Everything I said this morning is written down here in full, the way I said it, not a summary of it.

This page does not expire when the room empties. Bookmark it; come back to it after the four days that follow are over, when the two things you actually remember have blurred into one.

№ 01

The Eleven-Day Screen

The story I open every version of this talk with, because it's true, and because it's the whole argument in miniature.

I lead a product engineering team — a dozen or so people, spread across the globe, different countries, different time zones. One of our product managers wrote up a feature — a screen in our product, nothing exotic — and handed it to a developer several time zones away.

That handoff took eleven days to become working software. The answer, when I looked at why, was embarrassing. It wasn't a hard problem. It wasn't a slow developer. The developer would start building, hit a question the document didn't answer — what happens if this field is empty? — and stop. He'd message the PM. The PM was asleep. Twelve hours later, an answer. He'd build for an hour, hit the next question. Stop. Message. Sleep. Twelve hours.

The actual building took maybe two days. The other nine were questions, waiting to be answered, crossing oceans one at a time.

Today, in my team, an agent reads that same document before any developer ever sees it, finds those questions, and gets them answered — in one conversation, on day one.

That gap — between eleven days and one conversation — is what the rest of this page is about.

№ 02

Calculator, Consultant, Intern

Tap a row · one open at a time

The simplest way I know to explain where we are — three eras, told as one story.

If the rule-based era gave us calculators, and the LLM era gave us a brilliant consultant on the phone, the agentic era gives us something closer to an intern in the office.

For most of computing history, we had rule-based systems. Software did exactly what we told it — no more, no less. If the programmer didn't anticipate a situation, the software had nothing to say about it. All the intelligence lived in the human; the machine just executed.

Then, quite recently, came large language models. For the first time, we would say something, and the machine would say something impressive back. It could draft, summarize, translate, explain. But notice — it still only said things. It answered and waited.

The third era — the one this week is named after — is when we unbolted the chair. An agent doesn't just respond. It does things. It plans a sequence of steps toward a goal, it uses tools — searches a codebase, calls an API, reads a design file, writes a document — it remembers where it is in the work, and it decides what to do next. And like an intern, it needs supervision in proportion to what you let it touch.

№ 03

The Dial

People ask 'is this system an agent or not?' as if it's a yes/no question. It isn't. Agency is a dial, not a switch. Every agentic system sits somewhere on a spectrum of how much it's allowed to decide alone.

Drafts

human approves

Acts

human reviews

Acts

nobody looks

The interesting question is never 'can we build an agent that does X?' We nearly always can, now. The question is: how far do we turn the dial, for this task, with these stakes, and what do we put around it when we do?

Long context

Models that can genuinely reason over long context — an agent working on your codebase has to hold a lot of your world in its head at once.

Tool use

The model can now emit a structured call that says run this search, fetch this file, execute this function — and use the result. That was the moment language became action.

Cheap orchestration

You no longer need a research lab to wire an agent loop together. A single engineer with a laptop can do it in an afternoon.

None of these is magic. Each is an incremental step. But thresholds matter: when all three crossed at once, software that does things went from a research demo to something a mid-sized team — like mine — could actually deploy.

№ 04

Where Information Dies

The real story doesn't start with technology. It starts with what a normal week looked like before any of this.

  1. The vanished constraint

    The designer had decided — deliberately — not to put a delete button on a screen; that's dangerous here. It lived in a Figma comment. By the time a developer built the screen, that constraint had passed through three hands and two documents, and quietly vanished. Nobody dropped it on purpose. It just evaporated.

  2. The decision, re-made

    'Should this list be sorted by date or by name?' Decided, in chat, in seconds. Except the decision now lives in a thread, forever. Six weeks later somebody regenerates the document, the thread is buried under a thousand messages, and we make the same decision again — sometimes the other way.

  3. The spec that depended on who was tired

    Every PM writes differently — one writes three tight paragraphs, another nine pages, a third bullet points that make sense only to her. So the quality of what reached a developer depended on who wrote it, and frankly, on how tired they were that week.

THE REFRAME

Nobody was failing. The handoffs were.

Every person in that chain was locally doing sensible work. But at every boundary between two people, information decayed — a little context lost here, a constraint dropped there, a decision buried in chat. The team didn’t lack intelligence. It lacked process memory — a way for what one person knew and decided to survive, intact, into the next person’s hands.

You can't fix ‘people should be more careful.’

You can fix ‘information dies at this specific boundary.’

We didn't ask 'where can we add AI?' We asked: 'where does information die?'

Walk the chain in your own department. Replace 'PM' with 'professor,' 'developer' with 'research scholar,' 'feature document' with 'thesis chapter,' 'course file,' or 'committee minutes' — and I've just described any collaborative institution on Earth. Where does information die between you and your scholars? Between one committee and the next? That's where this technology belongs in your world.

№ 05

“Run the pipeline.”

What shipping a screen looks like in my team today — in principles and stories, not code.

A product manager points an agent at a design — literally pastes a link to a Figma file — and says: I need a technical spec for this. The agent opens the design, confirms what it found, sets up the working folder, and hands the PM a structured form: what should this screen do, who can see it, what must it never do. The PM fills in the product thinking — that part stays entirely human. Then the PM says four words.

Run the pipeline.

  1. Design link → readiness gate

    The orchestrator checks the PM's input for readiness — are the must-answer questions actually answered?

    What the human sees — A short list of what’s missing, or a green light to continue.

  2. Full spec

    It expands that thin input into a full technical specification — data, permissions, routing, copy, acceptance criteria — detailed enough that a developer, or a developer’s AI, can build from it without guessing.

    What the human sees — Nothing yet — this step runs unattended.

  3. Fresh-eyes audit

    It hands the spec to a second agent — fresh, with no memory of writing it — to audit against the actual codebase, not just the document.

    What the human sees — Nothing yet — the audit runs unattended too.

  4. Patch

    It fixes what the audit finds.

    What the human sees — Nothing — unless the audit found something no agent can safely resolve alone.

  5. Human questions

    It comes back to the PM with a short list of questions in plain conversational language: three quick ones from me, then two that are probably the engineer’s call, not yours.

    What the human sees — A handful of plain-English questions — the ones only a human can answer.

  6. Answers written back

    The PM answers, like they'd answer a colleague on Slack. The agent writes every answer into the documents — not the chat, the documents.

    What the human sees — The spec updates in front of them; nothing gets retyped by hand.

  7. Ready for a developer

    This screen is ready for a developer. One conversation. The eleven days of ocean-crossing questions happen in an afternoon, before a developer ever opens the file.

    What the human sees — A spec they can build from, with the questions already gone.

Watch what the pipeline never touches: the PM still decides what the screen should do, who can see it, what it must never do — the product thinking. Everything after that four-word sentence is the relay race; that part before it never was, and it still isn’t.

THE THESIS

This week you’ll learn to build agents in code. In my team, the orchestration language is English.

My team’s entire orchestration layer is made of documents — plain-English documents, in version control. The orchestrator itself is a document: here are your phases, here is what you read at each step, here is when you stop and ask a human, here is what you must never do. The quality gates are documents. The checklists are documents. The templates are documents. When we improve the system, we edit prose and commit it — like editing a constitution, not deploying a service.

№ 06

Three Decisions, Three Scars

Three design decisions inside this system I'd defend anywhere — each one paid for with a real scar.

I

Fresh eyes review the work — never the author

Every spec our generator writes is audited by a second agent with clean context — no memory of the writing — and for high-stakes screens, a genuinely different model altogether.

One day, the review agent was auditing a spec that was, I promise you, internally flawless. Consistent, complete, beautiful. Because we require the reviewer to check not just the documents but the actual codebase, it found something no human had noticed: a half-built implementation of the same screen already sitting in our repository, built months earlier, structured completely differently — different fields, different behaviours. A perfectly consistent document, silently at war with reality. Every document-level check in the world would have passed it. Only fresh eyes, pointed at the ground truth, caught it.

The lesson — Review must have access to reality, not just to the artifact. A reviewer that only reads what the author produced is auditing a story, not a system.

II

Hard stops, not helpful guesses

Early on, we let the agent be helpful when things went wrong. Design link doesn't resolve? It would improvise — guess the screen's name from the URL, scaffold something plausible, carry on cheerfully. It felt efficient.

It was a disaster in slow motion, because everything downstream inherited the guess, dressed up in confident, professional-sounding prose. Wrong, and persuasive about it.

The rule, rewritten — If the input cannot be verified, stop the entire process. Create nothing. Name what failed, plainly, and wait for a human. No fallbacks, no improvisation.

The most dangerous agent is not an incapable one — it’s a helpful one with wrong information. An incapable agent fails loudly and you fix it. A helpful agent with a wrong assumption fails fluently, and the error compounds downstream wearing a suit.
III

The human remains the author of decisions

Our agent has standing orders: it never invents a product decision. When it hits a genuine judgment call — should this action be irreversible? who is allowed to see this data? — it does not pick the plausible answer.

It marks the question and routes it to the human who actually owns that decision. It knows the difference between a product call, a design call, and an engineering call — and if the PM ventures a guess about someone else’s call, the agent records it as provisional, to be confirmed by the owner, rather than laundering a guess into a decision.

The lesson — The subtle failure mode nobody warns you about isn’t the agent making bad decisions. It’s the agent making reasonable decisions that were never its to make — and busy humans, quietly, stopping to check. Autonomy for logistics; humans for judgment. That’s where we set the dial — deliberately, task by task, not globally.

№ 07

One Human Number

Not a model benchmark. Not accuracy, not tokens, not latency. One number.

We track exactly one north-star number: clarification round-trips per feature. After a spec reaches a developer, how many times does that developer have to stop and ask a question the spec should have answered? Count them. That’s it. That’s the metric.

It needs no tooling — a developer can tally interruptions on their fingers.

Once a month, I sit with the log and ask one question: what single change to a prompt or a template would have removed the most round-trips last month? We make that one change. Just one. Then we measure again. No grand redesigns — one evidence-driven edit a month, compounding.

Measure outcomes, not artifacts.

It is astonishingly easy to build proxies — rubric scores, review checklists, quality gates — and we have all of those, but they measure the document. The round-trip count measures whether the humans downstream actually stopped suffering. For those of you who evaluate systems for a living: never let the proxy become the goal.

№ 08

What Travels

Four lessons I believe travel — beyond my team, beyond product engineering, into any serious deployment of this technology.

  1. Trust is engineered

    Nowhere did we decide to simply trust the agent. Every place it acts alone, there’s a gate in front and a fresh reviewer behind. Asking “do you trust AI” is the wrong question — like asking a civil engineer whether they trust steel.

  2. Verification should be boring

    Some of our most valuable safeguards are embarrassingly unglamorous — a plain, deterministic text scan, no intelligence involved. Probabilistic tools for generation, deterministic tools for checking.

  3. The hard problems are organizational

    The pipeline itself took a few weeks to build. What took months was everything around it — who owns the reference documents, who reviews the metric, what the escalation path is. Accountability never transfers to the tool.

  4. This changes what we teach

    If agents increasingly write the first draft of everything, the scarce human skills shift toward the two ends of the work — before generation, and after it.

№ 09

For the People Who Teach

Machines generate; humans constrain. If you teach engineers, this part is yours.

Before generation

Specification & the must-nots

Saying precisely what you want, what the constraints are, and — the underrated one — what must NOT be done. In my whole pipeline, the single most load-bearing artifact is the section where a human writes down the must-nots. Constraint-writing is becoming a core engineering skill, and I don’t know anyone who was formally taught it.

After generation

Judgment, with reality in hand

Reviewing critically, with reality — not just the artifact — in hand. Knowing what to check mechanically and what to check with your own head.

The generation in the middle — the part we spend most of our curricula teaching — is exactly the part the machines are eating fastest. I don’t say that to alarm you. I say it because the institutions that redesign around it first will produce the engineers everyone else is trying to hire.

№ 10

Your Week

Four days ahead of you, and — having seen the schedule — genuinely good ones.

  1. DAY 1 · MON 13

    Foundations of Agentic & Generative AI

    — the raw material.
  2. DAY 2 · TUE 14

    Building Intelligent Agents

    — the chair gets unbolted.
  3. DAY 3 · WED 15

    Multi-Agent Systems & Frameworks

    — the code-shaped version of the orchestration shown here in prose.
  4. DAY 4 · THU 16

    Industry Applications & Deployment

    — section 04 of this page, taught properly.
  5. DAY 5 · FRI 17

    Ethics, Security & Case Studies

    — everything about where the dial should sit, and what happens when it’s set wrong.

Everything I glossed over here, someone this week will open up properly. I’ve given you a map; they’ll give you the territory. Bring them your hardest questions — and bring your own institution’s workflows into every session, because that’s where all of this actually lands.

A few months ago, almost the same kind of screen came through our pipeline as the one I opened with. The agent read the spec before any developer saw it, surfaced its questions in one conversation over one afternoon, wrote the answers back into the documents — and the developer who picked it up built it without stopping once. Same people. Same time zones. Same oceans.

The people didn’t get smarter. The handoffs did.

Build agents this week. But remember what you’re really building: a new way for people to work together.