Module 2 · Building Agents · outlined
Agent Design, Prototyping, and Informal Benchmarking Session
Overview
Now you design an agent of your own — a conversation that makes something possible that wasn't: something software could not adapt to, or human effort could not scale. The possibility test from Module 1 is your design gate. Your proof of concept is not code — it is a set of conversations, and they will tell you whether your agent can complete the task, choose its words of action well, recover from surprises, and know when it is done.
How the session runs
Participants will work in groups of 2–3 to identify a real-world scenario supported by an actual or realistically simulated program or system.
We will impose a demanding design constraint: the proposed agent should enable something that was previously impractical or impossible. Perhaps conventional software could not adapt to the context. Perhaps the human expertise or labor could not be scaled. Perhaps a human could perform the task, but not quickly or cheaply enough for the required volume.
Each group will define the problem, the success criteria, the initial instructions, the tool set, the communication protocol, and the termination condition. They may prototype the computer participant in several ways. Programmers may use carefully reviewed scripts. Other participants may bridge the conversation to a real interface, carry out the requested actions, and return text or screenshots. Groups may also use a simple simulator or combine these methods.
The proof of concept is a set of conversations. Those conversations allow the team to test whether the agent completes the task, selects appropriate tools, recovers from unexpected results, respects boundaries, and terminates correctly. The goal is not yet a polished product. It is a fast feasibility experiment that reveals whether the proposed conversation can work.
This design becomes the initial form of the team's agentic research project.