Nadeem Ahmed
All field notes

Building with AI

Start with a workflow. Earn the agent.

A simple way to decide how much autonomy an AI product actually needs.

Start with the job.

When an idea becomes a product, the first question I care about is what someone needs to get done. That gives the system a purpose before it gives it an architecture.

An autonomous agent can be useful. So can a single carefully framed request. My preference is to give a system the freedom the task needs, and a clear way to show whether it succeeded.

Who decides the next step?

Anthropic’s foundational guide to effective agents draws a useful distinction. In a workflow, the application defines the path through its steps. In an agent, the model has more control over which steps and tools come next. Its tooling examples have evolved since the original 2024 publication; this architectural distinction remains useful for thinking about a product.

A fixed path fits work whose sequence is already understood. An agent becomes interesting when the next step depends on what it discovers and cannot easily be specified in advance. Extra autonomy also creates more behaviour to evaluate.

A small product example.

Consider a proposed feature that turns meeting notes into a draft follow-up. The work might be: extract agreed actions, flag missing information, draft a message, and let a person review it. The sequence is known. A modest workflow can make each stage visible.

Now imagine a broader research task. It may need to choose search queries, inspect documents, discover an unresolved question, and look for another source. The path is less predictable. That is a stronger reason to consider an agent.

These are design examples, not claims about products I have shipped. The decision comes from the shape of the work.

Keep the interfaces clear.

Anthropic’s guidance on tool design emphasises clear descriptions, meaningful context, and realistic evaluations. A useful tool should make its purpose and required inputs understandable. Adding more tools is not, by itself, evidence of a better system.

For the meeting-note feature, I would keep drafting separate from sending. That makes the boundary easy to explain: the user can inspect the work before it reaches anyone else. A research feature likewise needs a clear record of the material behind its conclusions.

Let results justify complexity.

Begin with representative inputs and a definition of success. Compare revisions against those same expectations. If a simpler system produces the right outcome consistently, its simplicity is valuable.

When it fails, identify why. Missing information, vague instructions, and a need for flexible planning are different problems. Only the last of those necessarily points toward more autonomy.

Sources & further reading

Explore field notes