From Chatbot to Crew

Day one had taken a chatbot apart on a whiteboard and named the pieces: interface, brain, memory, personality, decision pathways, tools. Six components, so that nobody in the room could use the word chatbot without knowing what was inside one.

The bot is the GPS, T. Valerie Onu told them that first morning. The human is the driver.

Everything since had been built on that frame. A dictionary bot that matched a question to a stored answer, and the quick discovery of how little that could carry. Guardrails, so it would refuse rather than improvise. The Golden Record, so every fact arrived with a source and a date attached. Retrieval, so the answer came out of a document the client owned rather than the model's memory of the internet.

By the start of week four the campers had a good bot. It had one shape, though, and the shape never varied: a question arrives, the system looks something up, an answer goes back.

One turn. One decision. One responsibility.

Real work does not arrive in that shape.

Before the AI, the workflow

The next move was not technical at all.

Campers were asked to look at ordinary, tedious business processes — the kind everybody has queued inside at some point — and take them apart as workflows. Not "applying for a loan" as a single event, but as a sequence: who touches it, in what order, what each person needs in hand before they can act, and what happens when the thing they need is not there.

That last question turned out to be the entire subject.

They practised on simulations before going anywhere near a client's problem, and the simulations were deliberately playful — issue a festival pass, walk an application end to end, step the sequence forward and watch what accumulates on the shared clipboard as it moves. The value of a simulation is that you can run it again, and break it on purpose. Nobody gets to do that with a bank.

Breaking it on purpose is where the learning actually sat. A workflow that only ever runs smoothly teaches nothing, because every real process spends most of its life in the exceptions. So each simulation shipped with its failures built in: the festival pass where the age proof is missing. The payment that fails. The identity document too blurry to read.

Only then did automation arrive — and it arrived as a question rather than a tool. Which of these steps could a system take? Which must a human keep? And what has to happen at the exact moment a step cannot complete?

Tariq is where that question got its worked example.

Tariq wants a loan

That is the whole premise, and it is deliberately ordinary. He walks into a bank — or opens a chat window, which by 2026 is the same thing — and asks for money to grow a business. What happens next is not one question with one answer. It is a sequence, and every step in it belongs to somebody different.

Somebody has to greet him and work out what he actually needs. Somebody has to establish who he is and what kind of customer he is. Somebody has to look up what the bank's own rules say about lending. Somebody has to check those rules against his documents. If something is missing, somebody has to go back and ask him for it — which means the sequence has to be able to turn around. Somebody has to inspect the result before it goes out. And somebody has to hand it back to Tariq in language he can use.

Ask a single chatbot to do all of that and it will try. It will also, somewhere in the middle, quietly invent a lending rule.

Why we taught it as a crew

This is the moment the camp stops teaching generative AI chatbots and starts teaching Agentic AI engineering.

A crew is not a chatbot with more prompts. It is the same problem broken into named jobs, each with its own inputs, its own constraints and its own right to refuse. Tariq's Digital Crew gave those jobs faces: Grace greets, Marcus profiles, Ava retrieves what the rules say, Daniel checks compliance, Maya interviews when something is missing, Theo inspects, Zara hands the outcome back.

Seven agents, one shared clipboard, and — the part that matters most — an edge that loops backwards. When Daniel finds a document missing, the work does not fail and it does not continue. It returns to Maya, who asks Tariq for the thing that is missing, and only then moves on.

Told as a story first

None of that lands as an architecture diagram on a Tuesday morning.

So it was taught as a story. The camp built comics for the agents, giving each one a character before it was ever a function, and produced a video walking through Tariq's journey from the request to the answer. Campers met Grace and Daniel and Maya as people with jobs before they met them as nodes in a graph.

That order was the point. A fifteen-year-old who has followed Tariq's application through seven pairs of hands already understands handoffs, state and conditional routing — they simply do not yet know those are the words. When the code arrives, it is not a new idea. It is their idea, written down in Python.

Then the hard part

Storytelling gets you to the idea. It does not get you to a production system, and the camp did not pretend otherwise.

The framework the campers were taken to was LangGraph, and it is worth being precise about what that means, because it is easy to assume a summer programme reaches for the gentlest tool available. It did the opposite.

LangGraph is a low-level framework. In software engineering, low-level means granular control and more explicit code — you are not handed abstractions that do the thinking for you. Where a high-level framework lets a developer declare an agent's role in plain English and trust the model to work out the steps, LangGraph requires three things to be written by hand:

Nodes — the precise code blocks or model calls that execute an action.

Edges — the conditional logic and decision paths connecting those actions, including the ones that loop backwards.

State — a central schema recording exactly what the crew knows at any given moment.

Because it hides none of that behind convenient abstractions, it gives absolute control over loops, self-correction and human-in-the-loop intervention. That control is the entire reason enterprises choose it. When a hallucinating agent could cost a bank money, you want a state machine with strict boundaries, not an autopilot that may wander.

Why low-level, specifically

The camp could have reached for a high-level framework. It would have been faster, gentler, and produced something demonstrable by the afternoon. It chose not to, and the reason was security.

In a high-level framework the model decides what happens next. That is the selling point — describe a role, and the system works out the steps. It is also, precisely, the attack surface.

Prompt injection works by getting text into a model's context that the model treats as instruction. If the model is only writing a reply, a successful injection produces a bad reply. If the model is also choosing the route, a successful injection chooses the route: skip the compliance check, reach a tool it was never meant to touch, return a figure nobody verified. One manipulated instruction, and the blast radius is the whole workflow.

Write the graph explicitly and that class of attack has nowhere to go. An injection can still corrupt what a node says. It cannot invent an edge that does not exist. It cannot route around Daniel, because Daniel is not a suggestion — he is a node the traffic passes through. It cannot call a tool the graph never wired up. The model's authority stops at the boundary of the node it is running inside.

That is what hardening means here. Not a filter bolted on afterwards, but an architecture in which the dangerous paths were never built.

It is also what made the day-nine lab worth doing. Campers spent a session trying to jailbreak their own bots, and that exercise only teaches something if there is a structure to test against. Break an autopilot and you have proved a model can be talked into things, which everybody already knew. Break a coded graph and you have found out exactly which node leaked and precisely what it was permitted to reach — a finding narrow enough to fix.

And it is why CUB-VA could state its invariant as flatly as it did: that it will never request, store or reveal confidential banking credentials — no account numbers, no passwords, no balances. An agent that decides its own next step cannot honestly promise that. An agent that only walks paths somebody wrote can.

What that actually asks of a learner

LangGraph is a direct implementation of graph theory and state machines applied to generative AI. Using it well calls on directed and cyclic graphs, data persistence and asynchronous programming — computer-science fundamentals, not chatbot tips. It is a staple of advanced university courses and production-grade AI workshops, and it is generally considered too advanced for someone building their first prototype.

It was taught to Caribbean teenagers in week four.

Where the field actually is

It is worth being clear about how recent all of this is. Retrieval and agent orchestration are not settled practice with a decade of textbooks behind them. They are the live problem in applied AI — being worked out right now, in production, by teams considerably better resourced than a summer programme.

The reason is that the model was never the hard part. Any organisation can call an application programming interface (API). What separates a demonstration from something a bank will put its name on is everything arranged around the model: where the facts come from, what the system is permitted to say, what happens when a step fails, and who it escalates to when it should not answer at all. That is orchestration, and it is where the genuine difficulty currently sits.

Which is the claim worth making about this programme, and it is a narrow one. The campers were not handed last decade's technology repackaged for schools. They were taken to the part of the field that is still being argued about — and asked to ship something in it.

class State(TypedDict):        # what the crew knows, exactly
    applicant: str
    documents: list[str]
    missing_items: list[str]
    compliance_status: str

def daniel(state: State) -> State:          # the NODE
    missing = required_docs() - set(state["documents"])
    return {
        **state,
        "missing_items": sorted(missing),
        "compliance_status": "pass" if not missing else "hold",
    }

def route(state: State) -> str:             # the EDGE
    return "maya" if state["compliance_status"] == "hold" else "theo"

graph.add_node("daniel", daniel)
graph.add_conditional_edges("daniel", route)   # loops back on a fail

The lab the campers worked through is public, and still is. It builds a retrieval agent line by line — what you type on one side, what LangGraph supplies on the other, and how each step maps onto the agent organisation you drew before you wrote any code.

What the campers came away with

So let's strip out the chatbot framing and look at what the twenty days actually transferred.

Graph theory, applied. Nodes, edges, directed and cyclic flow — not as an abstraction but as the thing deciding whether Tariq's application loops back or proceeds.

State design. A schema for what a system knows at any given moment, and the discipline of reasoning about what happens when part of it is missing.

Control flow under uncertainty. When to retry, when to halt, when to stop and hand to a human. Most software assumes it will succeed; agents have to be written by someone who assumes they will not.

Retrieval over a governed corpus. Grounding an answer in a source somebody owns, and citing it.

Adversarial testing. Day nine was campers attacking their own systems on the principle that you should think like a hacker and build like a defender.

Output validation. Schema checkers, refusal conditions, and the habit of not trusting a model's output because it reads well.

Deployment. FastAPI to GitHub to Render, and a start command that has to be exactly right.

And Python, to an externally examined standard.

The first seven are the ones a hiring manager would recognise as senior. The last is the one that fits on a certificate. What is not on any list is the judgement underneath all of it — knowing when a system should refuse — and that is the part you cannot look up.

The transfer

Rigour of that kind only counts if it survives contact with a real client, and this is where the twenty days can be audited rather than described.

W.E.S routes an emergency before it collects a name — a conditional edge, taken because a flooded yard cannot wait behind an identity check. A.I.D.A. escalates to a staff console rather than improvise a ruling on tax — a human-in-the-loop node, placed exactly where being wrong costs most. ASPIRE AI added output-schema checkers after its agents got tangled in multi-turn testing, which is a state problem diagnosed and repaired by the people who caused it. PILOT hands anything touching customs to a port dispatcher — a halt condition, written deliberately rather than hoped for.

Those are not features anyone thought to request. They are what a graph looks like when the person drawing it has understood that the hardest part of an agent is knowing when it must stop.

On stage, watching their own system hand off correctly under pressure, one team put it more plainly than any of this: That is what agentic means in practice!