PSG · 11 August 2026 · 60 min · 6 live demos
Built live in Colab · why the hard part was never the model
Foundations
A call is a function. Text in, text out. It cannot look anything up, and it cannot take a second step.
It can reach past its own context and act on something real.
It can take a next step based on what it just learned.
It decides when it is finished. You did not write the stopping condition.
Those three, and nothing else. Every framework you will read about this year is packaging around them.
Foundations
Who picks the next step?
Nobody. There is no next step. One turn, then it stops.
You do, in code. You wrote the sequence and you know it in advance.
The model does. You do not know the sequence, because it depends on what it finds.
This is the only line that matters. Everything else — frameworks, diagrams, vendor names — sits on top of it.
Notebook §1 · same question, once without tools and once with two
Foundations
If you can write the steps down, write them down. A for loop is cheaper, faster, debuggable, and it will not invent a fourth step at two in the morning.
Reach for an agent when the sequence depends on what you find. Our second tool call was decided by the answer to the first. Rename those metrics and the plan changes, with no code edit.
That flexibility is the entire purchase. The rest of this hour is what it costs.
Foundations
One agent with tools just solved that on its own. So why add another?
One agent reads fifty documents and hands forward a page. The next never carries the fifty.
The agent that reads the database should not be the agent that sends email. That is a security boundary.
Ten independent files, ten agents, one wall clock.
Notice what is not on that list: “so each one can specialise in a role.” That is the reason almost everyone actually reaches for, and it is the weakest one.
Opening
You have a hard task. You give it to one agent. It does a mediocre job. So you do the obvious thing.
01
Add a researcher agent to gather the facts.
02
Add a writer agent to draft from what the researcher found.
03
Add a critic agent to review the draft.
04
Add a manager agent, because now somebody has to coordinate the other three.
Four agents. It is slower, costs roughly four times as much, and the answer is often worse.
Why That Happens
Every arrow between two agents is a place where context gets repackaged, summarised, and paraphrased. The task survives the trip. The understanding of the task does not.
You have met this before. Brooks wrote it down in 1975: adding people to a late project makes it later, because the communication paths grow faster than the workers do.
Agents are not exempt. They are worse, because they never say "wait, I don't follow."
Ask a four-agent system why it produced a particular answer.
You get a plausible reconstruction, not a trace. Nobody kept the evidence, because the handoffs were prose, and prose does not carry proof.
An answer nobody can account for is not an answer. It is output.
Part I · 15 min · demos A, B
Notebook §3 – §4 · one agent, then four in a chain
The Reframe
Every boundary charges a toll. Agent to agent, agent to human, run to run.
Design the boundaries badly and a better model will not save you.
Scoring It
Score each low / medium / high for your workflow. Then fix the top one or two, not all six.
Context repackaged agent to agent. Raised by many sequential agents.
Detail dropped to make context fit. Raised by summarising between steps.
Meaning mutates across paraphrases. Raised by free-text handoffs with no schema.
What it costs to check the output is right. Raised by opaque results with no evidence.
Raw compute of moving context. Raised by re-sending large windows every hop.
Permissions, approvals, audit. Raised by unclear authority and manual sign-offs.
The Levers
| Sink | Lever |
|---|---|
| Handoffs | Fewer boundaries. Shared state instead of relay. |
| Compression loss | Keep a source of truth. Summarise for display, never for the next step. |
| Semantic drift | Typed handoff schemas. A structured contract, not prose. |
| Verification burden | Evidence travels with the output. Validate the trace, not the vibe. |
| Tokens & latency | Pass references and IDs, not full payloads. |
| Governance | Explicit permissions, written into the interface. |
Notice that none of these are "use a bigger model."
Notebook §5 · where the note actually went
Part II · 15 min · demos C, D
Five Shapes
Agents read and write a common evidence store.
PreferA policy picks the structure per task.
BestAgents argue to consensus in free text.
WorstA manager agent routes the work.
LossyA fixed sequence, every time.
BrittleThe bottom three are agents imitating human meetings. That imitation is the tax.
The Worst Case
Three agents arguing to consensus feels rigorous. It is the opposite, for two reasons.
Correlated deliberation. Same base model, same training, same blind spots. Three votes, one opinion. You have bought agreement and mistaken it for confidence.
No evidence preserved. The argument happens in prose and evaporates. What survives is a conclusion with no trace.
Give them a shared store. Each agent writes findings with provenance, reads what others wrote, and disagreement becomes a visible conflict in the data rather than a louder paragraph.
Now a human can look at the conflict and decide. That is the whole point.
Notebook §6 · shared board + typed handoffs
The Counterintuitive One
Every time you want to add an agent, one question: is it genuinely independent?
A different model.
A different tool.
A different evidence source.
It can be wrong in a way the others cannot. That is what adds signal.
The same model with a rephrased prompt, wearing a different job title.
Pseudo-diversity. It adds cost on every boundary and contributes no independent signal.
Most "multi-agent systems" are one model in five hats, paying five times for one opinion.
Notebook §7 · personas, then a second evidence source
Part III · 8 min · demo E
The Contract
Anywhere machine output enters a human workflow or another agent. Miss one and the boundary is un-checkable.
Which outputs may cross at all.
The trace the receiver can actually check.
So confidence is not laundered on the way across.
What the producing agent was allowed to do.
What is kept for audit afterwards.
Where a human must decide — and who that human is.
Notebook §8 · six fields, and a name
The One That Gets Skipped
At every point where a human must decide, one named person has to be able to answer three questions about what the machine produced.
Not the team. Not the system. A person, with a name.
A boundary with no answerable owner is where the machine ships unowned work.
Every automation failure you will read about in your career has this shape: the output was plausible, it crossed a boundary nobody was accountable for, and by the time it was wrong it was in production.
You cannot delegate this one to the architecture.
Part IV · 5 min
The Part That Isn't New
Everything so far has been about systems. This is the part that was never about the tools.
You did it on purpose, and you can say why.
You want to know how it works, not just that it worked.
You don't cut the corner nobody would see.
You can hold a problem open before you close it.
A course can teach you principles and methods. It cannot make you any of these. Neither can the machine: it takes instruction rather than intent, and it cannot sit in ambiguity — it resolves to the average, every time.
Think For a Minute
Two questions. The first one is uncomfortable, so be honest with yourself.
Your course gave you principles and methods, and that is the part that transfers. What it could not give you is the disposition. Unlike the methods, you build that by doing the work, which means you are not behind. You are early.
Take It With You
Build the smallest system you can actually account for. Then make it bigger only when something forces you to.
Run it yourself. The notebook behind all six demos, on a free AI Studio key.
colab.research.google.com/drive/1brSW2oJTzEi4_0bd2698pYjEQVsEfJSr?usp=sharing
Then, when you want the production shape of this: Long Horizon, a reference agent harness in Google’s ADK samples (sample code, not a supported product) — github.com/google/adk-samples → core/python/long-horizon-harness