Start With the Work

Agent projects often begin with a model name and search for a reason to exist afterward. That reverses the order. A model is a capability inside a system; it is not the system. Start with the work, because the work tells you whether you need language reasoning, deterministic code, a database lookup, browser control, a person, or some combination.

A useful workflow has a recurring trigger, meaningful context, a decision or transformation, and an outcome worth verifying. If you cannot point to those elements, adding an agent will mostly add uncertainty.

The official process is rarely the real process. The real version includes the spreadsheet someone checks first, the Slack message that supplies missing context, the judgment call that only one teammate knows, and the manual cleanup nobody documented. Map those details before automating anything.

The visible action is rarely the whole job. Sending a payment follows validation and approval. Closing a support ticket follows diagnosis and confirmation. Publishing a campaign follows evidence, drafting, brand review, and legal review. Provisioning an employee account follows identity, role, and access decisions. Automating only the final click makes a faster bad process.

Do not automate the entire department. Find a seam: one bounded handoff where the input is available, the desired output is clear, and failure is recoverable. Good first seams include preparing a research brief, converting notes into structured tasks, classifying inbound requests, or verifying that a deployment matches a checklist.

The seam should be valuable even when a human reviews every result. That keeps the first version safe and gives you labeled feedback for improving the system later.

A workflow contract tells the system what it may assume and what it must return. Specify the required fields, allowed tools, time horizon, approval points, output format, and failure behavior. The contract should be understandable without reading the implementation.

This is where an operator’s discipline matters. If the system cannot find the source data, it should say so. If confidence is low, it should ask. If the action changes money, access, public content, or another person’s work, it should pause for approval.

A workflow can look impressive while quietly moving work somewhere else. A draft that requires a full rewrite, a summary nobody trusts, or a task list without owners is not leverage. It is a new queue.

Measure the burden around the output. Did review time fall? Did error recovery improve? Did the next person receive better context? A system is useful when the full loop gets cheaper or more reliable, not when the agent appears busy.

A workflow description usually sounds linear: receive request, do work, deliver result. The real system is a state machine. A request may be incomplete, ready, running, waiting for approval, blocked by a dependency, failed with a recoverable error, completed locally, or verified live. If those states are not explicit, they leak into chat messages, booleans, and human memory.

Start by naming the states a responsible operator would need to distinguish. Then name the event that moves the work between them and the evidence recorded at each transition. ‘Running’ should require an executor identity and a recent event. ‘Awaiting approval’ should preserve the proposed action and review packet. ‘Complete’ should require the receipt defined before execution began.

This model makes the workflow debuggable before it makes it autonomous. You can see whether a failure belongs to intake, context retrieval, routing, execution, approval, verification, or delivery. That is much more useful than a generic red task card.

Not every repetitive task deserves an agent. Score candidate workflows on frequency, value, clarity, context availability, reversibility, and evaluation cost. High-frequency work with clear outcomes and cheap verification is an excellent first target. Rare work with ambiguous success, sensitive data, and irreversible actions is a research project—not an automation quick win.

Also distinguish deterministic automation from model-shaped work. If a stable rule can produce the correct answer, use code. If the task needs interpretation across messy language or open-ended search, a model may help. If the path itself must change based on observations, an agent loop may be justified. Complexity should enter because the work requires it, not because the architecture diagram looks impressive.

A useful rule is to buy uncertainty only where it creates value. Keep identifiers, permissions, money movement, state transitions, and validation deterministic whenever possible. Use models for the semantic judgment between those rails.

Before automating the workflow, collect a small set of representative cases: straightforward examples, edge cases, missing-context cases, and dangerous cases. Write what a good result looks like and what must never happen. This becomes the first evaluation set and prevents the demo case from defining the entire product.

Evaluation can begin manually. Review outputs against a rubric, record the error category, and keep the input with the corrected result. As volume grows, automate the deterministic checks and preserve human review for judgment. The important move is separating ‘the system ran’ from ‘the result was good.’

This also gives you a stopping condition. If the workflow cannot be evaluated consistently by a person, it is not ready for more autonomy. Clarify the decision or reduce the scope before adding another agent turn.