Small automated tools, clear responsibilities

A collection of small tools can be easier to understand when each has a specific responsibility. The challenge is making the connections between those tools as clear as the tools themselves.

The useful starting point is the work, rather than the number of agents. Which part is repetitive? Which part needs judgement? Where does a person need to make the final decision? Those questions create a more useful architecture than beginning with an impressive diagram of connected models.

Start with the boundaries

Describe the input, output and responsibility of each stage. Keep the purpose narrow enough that a result can be reviewed. If a stage makes a judgement, distinguish that judgement from information copied directly from a source.

Consider a catalogue assistant. One step could read a product record. Another could identify missing attributes. A third could propose a clearer description. These are related tasks, but they produce different kinds of output. A missing storage value is an observation; a suggested product description is a proposal. Treating both as confirmed product data would erase an important distinction.

Make handoffs explicit

A later stage should know what an earlier result means and whether it is complete. Use visible states for missing information and human review. A well-defined handoff helps prevent uncertainty from being passed forward as if it were a confirmed fact.

A useful handoff can be quite small:

• The record being worked on and its source.
• The result of this stage, with missing information called out.
• The next action that is permitted.
• A reason to pause when that action cannot proceed.

This also makes the interface easier to design. The same information that guides the next tool can explain the current state to a person reviewing the workflow.

Keep a person in the loop

Design a way to pause, inspect and correct the process. The controls should match the consequences of the action, with meaningful review before consequential changes. Small tools are most useful when their combined behaviour remains understandable to the people responsible for them.

In the catalogue example, reading a public product page and publishing a new description are different decisions. The first can support a draft; the second changes what customers see. A review should show the current description beside the proposed one, identify the source information and make editing or rejecting the proposal straightforward.

Make the smallest useful version

A first version does not need a large collection of autonomous roles. A single clearly bounded workflow, a visible draft and a good review screen can reveal whether the idea saves useful effort.

Try a varied set of inputs: a complete record, an incomplete one, a contradictory one and an unavailable source. Inspect where the process becomes uncertain. Those moments tell you what to improve next, whether that is the data, the instructions or the handoff itself.

The goal is a tool someone can understand, trust appropriately and keep using. The architecture should help that happen.