Start with a bounded job
Agentic engineering is the work of designing, implementing and evaluating systems in which a model can select actions to pursue a goal. The hard part is often deciding exactly what the system is allowed to do, what completion means and how a person can inspect the result.
Anthropic distinguishes workflows with predefined code paths from agents that dynamically direct their process and tool use. Its guidance favors simple patterns when they solve the problem. For a predictable task, a workflow may be easier to understand and test than an open-ended loop.
Design the tool contract first
For a hypothetical planning assistant, start with a limited job: turn a request into a draft schedule. A tool could read permitted availability, another could validate a draft, and a separate operation could commit approved changes. Each tool needs typed inputs, clear error responses and an explicit description of side effects.
Keep credentials and authorization in application code. Model output can propose a tool call; it should not grant the permission to perform it. Treat text retrieved from documents or external services as untrusted data, particularly when it appears to instruct the system to change its goal or disclose information.
Keep the proposed change visible
A useful interaction pattern is request, draft, review, confirm, apply. Show the person what will change before consequential operations happen. If a draft moves an appointment, the interface should show both the current value and the proposed value, not only a reassuring summary.
LifeFlow's review-first product direction uses an editable Plan Draft to keep people involved in decisions about their day. The broader engineering lesson is to make intent and effect legible: a person should be able to understand the plan, amend it and decide when it is ready to become an action.
Engineer for partial failure
Imagine that the first step succeeds but the network drops before the response reaches the agent. A blind retry could duplicate the change. In our recommended design, mutating operations use idempotency keys or another duplicate-prevention mechanism, and the application records whether each operation is pending, applied or failed.
Set limits on tool calls, elapsed time and spending. Preserve enough state to resume or stop without guessing what happened. For actions that cannot be automatically reversed, describe the failure clearly and provide a recovery path. A trace is useful only if it records meaningful events without collecting unnecessary sensitive content.
Measure the outcome people care about
Write acceptance scenarios before expanding autonomy. Can the system complete the bounded task? Does it ask for missing information? Does it stop when permission is absent? Does it recover from a failed tool call without inventing success? Include adversarial input and stale data alongside the happy path.
Track task completion, incorrect actions, required corrections, time and cost. Use those results to decide whether another tool or a more autonomous loop is justified. Dependability comes from the whole system: product boundaries, software controls, model behavior and the person's ability to remain in charge.
Sources & further reading
Original commentary by Harmosoft, with the following references for the underlying concepts.
See the product philosophy behind review-first planning intelligence.
Discover LifeFlow↗