Drawing an Agent System
By the end of this module
- Place the course vocabulary onto one design, in the order worth asking
- Read what a notation reports back that nobody wrote into it
- Say why a drawing that cannot describe an absence is only a picture
Definition
Everything in this course has been one idea at a time. This module puts them on one page, using the notation this knowledge base uses for designing agent systems.
The claim worth testing is that drawing is a thinking tool rather than documentation. A documentation diagram records a decision somebody already made. A notation with a closed vocabulary makes you answer questions you were going to skip, and then tells you which ones you skipped anyway.
Walking a Design
One design, built in the order the questions are worth asking. Step through to the end.
Start outside the system. A channel carries the shape of the work and its latency budget, and naming it stops the design drifting towards whatever is easiest to build.
Nothing in the first five stages is new. Channels, agents and sub-agents, tools and binding, knowledge and state, requirements and controls, typed exits: each was its own module. What changes here is that they are forced to coexist, and the places they disagree become visible.
What the Drawing Reports
The last stage is the point. Four findings, none of which anybody typed into the design.
Seven of the eleven exit types are not modelled. That is not a criticism of the design, because most of them may be genuinely impossible here. It is a question nobody would have asked, and the answer is either a deliberate waiver or a gap in instrumentation. An open vocabulary cannot produce that line at all, which is the argument for a closed one that the typed exits module made in the abstract and this makes concrete.
One obligation is prompted rather than enforced, and it is the same one a model judge waved through two modules ago. Reaching it from three directions is the strongest evidence the course can offer that the distinction is real.
Drawing Rules Worth Knowing
Three conventions carry most of the value, and the first is the one most hand-made diagrams get wrong.
| Rule | Why it matters |
|---|---|
| A control sits beside a stage, never in it | Drawing a guardrail as a step in the flow is the commonest error in a hand-made agent diagram. A check drawn as a step invites being built as a tool the agent may call, which makes it discretionary and therefore not a control. |
| Containment is the only way to attach | A tool belongs to an agent by sitting inside it. One spelling means a reader never has to work out whether two notations mean the same thing, and it is what lets the layout be derived. |
| The workflow links agent to agent | Pointing a transition at something inside another agent couples the caller to how that agent is built. Internal steps connect to each other; exits may leave from inside, because giving up is a fact about the step that gave up. |
| An unverified element is marked as such | Designs are drawn before the facts are in. Tagging an assumption keeps it visible in the findings rather than letting it harden into something everyone believes was checked. |
A team draws their agent system and the notation reports six unmodelled exit types. What is the right response?
Discussion
Before the capstone, agree one thing as a room: which system you are going to design next session. It should be a real decision somebody owns, small enough to draw in forty minutes, and something at least one person in the room disagrees about.