15.S50 ↖ Session 3 · Technical note
Draft Working document · developing with Kate · not yet released to students
15.S50 · Session 3

Technical note

Read this before class. It is short on purpose, it gives you the vocabulary we will use in the room, not the answers we are going to argue about. 15.S50, Session 3.

What we mean by an agent

An agent, here, is software that can take a task from start to finish on its own. It can verify who it is dealing with, pull the records it needs, reason about them against a set of rules, and act, all inside guardrails a human set. The line that matters is not chatbot versus agent, it is how much of a job the system finishes before a person has to touch it, and which parts it is trusted to finish alone.

Two paths, and why the second one exists

Most real deployments run two paths at the same time.

The fast path is where the agent handles the routine work end to end. This is most of the volume, and it is cheap and consistent. A caller asks for a balance or reports a lost card, and no person is ever involved.

The slow path is where the work goes to a human. This is the exception: the judgment call, the angry customer, the decision that moves money or carries legal weight. The agent usually does not disappear here. It often reads the account and lays the facts out so the person is faster, but a human owns the outcome.

Most of the design work is deciding what belongs on which path, and when it is safe to move something from the slow path onto the fast one. That coordination has a name, orchestration, and it gets harder as the number of agents grows.

Narrow tools and general ones

Some agents are built to do one job on one system. Others are built as a general capability that can be pointed at more than one job. From the outside the two can look identical, and the difference matters more than it looks like it should. We will spend a good part of class on why.

What scale costs

Building an agent is one question, and running it, then running ten of them, is another.

So “can we build this” and “can the organization absorb five more of these” are different questions, and a leader has to answer them separately.

What to bring to class

We will work through a real decision a leader faced, using one case. Three questions sit underneath it. Hold them as questions, we will argue the answers in the room.

  1. When is it worth making something reusable, instead of letting each team build its own version?
  2. How do you coordinate more than one agent, and where do the exceptions go?
  3. How fast should you scale, and what breaks if you move too fast?