Three AI Agents in Sixty Minutes: Parallel, Router, Dynamic

Sixty-six people filled in the registration form before this session, and every slide in the deck came from something one of them wrote there. That form turned out to be the most useful thing we did all week.

Nineteen of the sixty-six said they wanted to build agents — often with no further detail than those two words. I don't read that as a lack of interest. I read it as a missing vocabulary: people know there is something here and don't yet have the words to say which part of it they want.

Six asked about guardrails, evaluation, production and lifecycle. Six. That is the part where projects actually die, and it was the least-requested topic in the room. So we built the session around closing that gap: enough theory to make the rest make sense, then an hour of hands-on building, then the unglamorous material that decides whether any of it survives contact with a real user.

01 / Twenty Minutes of Theory

You are the loop, or the loop closes itself

Almost every argument about what counts as an agent dissolves once you draw the two diagrams next to each other.

A chatbot goes prompt → model → answer, and then it stops, because a human decides what happens next. Every step waits for a person. An agent goes goal → decide → act → observe, and then it goes round again, because the observation feeds the next decision. Human-in-the-loop becomes optional — and that word optional is the whole distinction.

The practical test I gave the room: remove the human from the middle. If anything still happens, it's an agent. If nothing happens, you have a very good chatbot, which is a perfectly respectable thing to have.

Five components, and the one everyone forgets

Whatever architecture you end up with, it decomposes into the same five parts:

• ModelDecides the next action. Swappable — design assuming you will swap it.
• ToolsHow it touches the world. Most agent quality actually lives here.
• MemoryRun state, plus whatever survives between runs.
• OrchestrationThe loop: continue, stop, retry, escalate.
• EvaluationThe forgotten one. Without it, every change is a guess.

Nearly everyone builds one through four, ships, and then cannot answer the only question that matters six weeks later: is it getting better or worse?

Two things worth saying about the first two. Great tools beat a great model — narrow, well-named, structured results, clear errors. get_customer_by_email beats query_database every time. And route per step, not per project: a cheap model for the classification steps, an expensive one for the single hard step.

Then there's the honest list — hallucination, cost, context rot, a training cutoff that doesn't know your Q3 numbers, arithmetic and dates it should never be doing, and non-determinism that makes “it worked when I tested it” stop meaning anything. Plus the three nobody puts on their slide: silent failure (normal code screams when it breaks; an agent produces a confident, well-formed, wrong answer and moves on), prompt injection (live the moment it reads a document or an email), and uniform confidence — it sounds exactly as sure when guessing as when certain. That last one is what makes the errors dangerous.

Half of that list is solved by tools, not by a better model. That's why the system around the model exists.

02 / Sixty Minutes Hands On

Three architectures, built live

There are seven agent architectures on the map we handed out. Three of them are worth learning first, and those are the three we built.

Parallel: a competitive intelligence dashboard

Emily's build was three research agents launched at the same moment — Calendly, Reclaim.ai and Motion — each gathering GitHub activity, positioning, pricing tiers, blog posts and job listings. Five public sources per competitor, no API keys, no auth. A merge agent reconciles the three JSON files into one analysis; a dashboard agent renders it as HTML with competitor cards, a scoring matrix and white-space gaps.

The reason the fan-out is legal is that none of the three lookups needs another one's answer. Add a single dependency and it collapses into a sequence wearing a parallel costume.

Router: one messy email, three departments

Yash opened with a real customer message — dashboard crashing on PDF export, wants fifty more enterprise seats, says the API rate-limit docs are useless — and asked the room to shout out how many issues were hiding in it.

Then he showed why a router agent is not a CC rule. A CC rule stops at level one. A router does three things: classify by meaning rather than keywords (it knows “about to cancel” is churn, not billing), decompose the message into separate tasks, and tailor each piece for its specialist, stripping everything that isn't theirs. Three drafts came out: engineering got the bug, sales got the expansion flagged for human approval because it touches revenue, product got the docs feedback. Nobody triaged anything.

Dynamic: the agent that picks its own team

My build was a sub-agent orchestrator for inbound leads. It reads one lead, classifies deal size, seniority and urgency, and writes a spawn_plan.json — and only then decides which specialists to wake up. The ICP scoring agent and the email agent run every time. Company intel runs if the deal is over $10k. Buyer persona runs for VP and above. Competitor usage runs at $50k or a hundred-plus employees.

That's the whole distinction between Type 4 and Type 7. In Emily's demo, you chose the branches. Here the agent chooses them, at run time, from the same input shape.

The most interesting part of the output isn't the lead brief. It's the decision box showing which agents fired and which were skipped. And the four thresholds live in code, not in the prompt — business rules you can unit-test beat business rules the model re-derives on every run.

03 / The Part Six People Asked About

Chat is a demo. Triggers are a product.

Here is the uncomfortable framing I left the room with. In a chat session you are the scheduler, the input provider, the error handler and the delivery mechanism. You decide when to run it, gather the inputs by hand, notice it went wrong by reading, and copy-paste the result somewhere real. Replace all four and you have a product: a trigger, a data connection, validation that fails loudly, and a destination.

Before you automate anything, label every step in the workflow — including the informal ones, because “and then someone eyeballs it” is a step. MOVE steps (fetch, copy, transform, route) are code; most steps people plan to hand a model are these. JUDGE steps (classify, extract, summarise) are what the model is for. CHECK steps are code first. DECIDE steps — approve, commit, spend, send — are a human or a very hard rule. Automate a contiguous run that ends at a DECIDE. That's your v1 and your human checkpoint in one.

And guardrails are four layers, not one thing: input constraints stop it starting wrong, execution constraints bound the damage, output validation gives you mechanical truth, and only then a judge layer for what code genuinely cannot check. Every check you move up that stack is cheaper, faster and more reliable. Teams reach for the judge first because it's the interesting layer.

The demo is 20% of the work. Knowing that ratio upfront is what stops a project stalling at “nearly done” for three months.

Where you go from here

If you came to understand it: the model is the least important part. Learn the loop around it and you'll understand every product you see for the next five years.

If you came to ship it: your test set is the product. Build it before you build anything else and everything downstream gets easier.

If you came to govern it: write down what correct means, and attach a human name to it. That's more than most governance programmes manage in a year.

Feynman said you can know the name of a bird in every language and still know nothing whatever about the bird — so look at the bird and see what it's doing. Same advice here. Stop naming it. Watch what it does.

Pick one boring, repetitive, high-frequency task — ideally one that's slightly embarrassing a human ever did by hand — and follow it all the way through to something that runs without you. It will be broken by Thursday. That's when you actually start learning.

Thank you to Emily Mao and Yash Sanghvi for building live in front of a room, to Yuliya Roshko for the introduction, and to Igniter Silicon Valley for the space. Everything in the deck is something that broke on me first.

Try the builds: type4 — parallel · type5 — router · type7 — dynamic. Keep going: the peer group · ignitersv.com.